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I.  Introduction 

The  purpose  of  this  report  is  to  review 
the  current  state  of  systems  technologies 
as  they  relate  to  shipbuilding  production 
processes.  The  focus  is  on  the  areas  of 
computer-aided  manufacturing  (CAM), 
numerical  control  (NC),  and  enterprise 
resource  planning  (ERP).  However,  the 
report  also  addresses  the  areas  of 
computer-aided-design  (CAD)  and 
product  data  management  (PDM). 
Although  these  latter  areas  are  more 
appropriately  in  the  design  and 
engineering  realm,  the  information 
created  in  these  systems  provides  the 
foundation  for  many  production 
processes.  Some  potential  improvements 
in  production  process  rely  heavily  on 
changes  or  enhancements  in  the  design 
systems.  Moreover,  this  report 
emphasizes  shipbuilding  specific 
requirements,  system  capabilities  and 
opportunities.  Systems  technology 
support  for  the  shipbuilding  industry  is 
built  largely  on  top  of  systems  that  have 
been  developed  in  support  of  the 
requirements  of  other  industries.  One  of 
the  challenges  is  to  understand  where 
those  other  requirements  coincide  with 
shipbuilding  requirements  and  where 
they  diverge.  With  such  an 
understanding  it  is  possible  to  plan  when 
to  let  other  industries  drive  systems 
technology  and  to  identify  those  areas 
where  the  shipbuilding  industry  needs  to 
be  more  proactive. 

Previous  research  has  been  done  in  this 
area  in  recent  years.  In  2001  NSRP 
published  an  industry  report, 
Benchmarking  of  U.S.  Shipyards.  In 
1997  NSRP  published  an  Evaluation  of 
Shipbuilding  CAD/CAM/CIM  Systems. 
Phase  I  of  the  report  was  an  evaluation 
of  existing  systems  (NSRP  0476)  and 


Phase  II  was  requirements  for  future 
systems  (NSRP  0479).  There  has  been 
considerable  activity  in  the  past  five 
years,  and  a  second  look  at  current 
CAD/CAM/CIM  capabilities  is  timely. 
The  NSRP  Benchmarking  report  did  not 
address  systems  technology  directly,  but 
it  did  define  a  set  of  best  practices, 
largely  production  processes,  and  ranked 
U.S.  shipyards  against  overseas 
competition.  The  ranking  indicated  those 
process  areas  in  which  there  was  room 
for  improvement.  The  results  of  the 
Benchmarking  study  have  been  used  to 
identify  the  process  areas  that  are 
addressed  in  the  current  report.  This 
report,  while  organized  around  best 
practices  themes,  does  not  attempt  to 
rank  individual  shipyards,  but  rather  it 
describes  the  state  of  the  art,  of  systems 
technology,  as  it  applies  to  each  of  those 
themes.  The  Benchmarking  report 
concluded  that  although  US  shipbuilders 
were  improving  in  productivity,  so  was 
the  competition.  The  recommendation 
was  that  the  typical  medium  or  large 
shipyard  should  seek  a  75% 
improvement  in  productivity  over  the 
next  five  years.  The  report  further 
concluded  that  because  US  shipyards 
have  a  high  cost  base,  there  needs  to  be  a 
deliberate  effort  to  offset  that 
disadvantage,  and  that  that  could  be 
accomplished  by  means  of  advances  in 
systems  technologies. 

The  Benchmarking  report  also  contained 
a  number  of  specific  findings  in  each  of 
the  best  practices  themes.  One  area  that 
was  highlighted  was  accuracy  control. 
Accuracy  control  is  essential  for  error- 
free  manufacturing,  yet  it  is  not  well 
supported  in  US  shipyards.  The  costs 
associated  with  poor  performance  in  this 
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area  are  far-reaching.  Low  scores  in  the 
erection  and  fairing  best  practice  area 
were  specifically  attributed  to  this 
shortfall.  Another  best  practice  theme 
that  scored  low  was  outfitting.  The 
conclusion  was  that  there  needs  to  be 
better  means  for  delivering  more 
appropriate  technical  data.  In  addition, 
U.S.  yards  could  benefit  from  more 
effective  design  for  production.  The 
report  recommended  the  formalizing  of 
the  shipyard’s  build  strategy.  These 
recommendations  argue  for  more 
effective  management  and  use  of 
manufacturing  and  related  data. 

The  CAD/CAM/CIM  evaluation  report 
described  the  CAD/CAM/CIM  systems 
that  were  in  place  at  the  time  (1997)  at 
several  overseas  shipyards.  The  report 
provided  a  detailed  description  of  the 
deployments  at  each  yard,  including 
such  items  as  the  network  infrastructure, 
operating  systems,  and  databases  in 
place  at  the  time.  Of  course,  the  focus 
was  on  which  CAD  and  CAM  systems 
had  been  implemented.  The  report  also 
described  the  degree  of  customization 
that  had  been  done  as  well  as  the 
circumstances  under  which  the 
customization  was  accomplished.  One  of 
the  objectives  of  the  report  was  to  assess 
which  functional  capabilities  were  being 
supported  by  systems  technology.  The 
report  also  included  a  paper  evaluation 
of  the  CAD/CAM  software  packages 
that  were  being  used  at  the  shipyards. 

The  CAD/CAM/CIM  evaluation  re¬ 
iterates  a  position  with  respect  to 
systems  technologies,  which  is  generally 
accepted  as  a  truism  among  shipbuilders. 
The  position  is  that  systems  technologies 
are  secondary  to  business  processes.  “A 
major  finding  relates  to  the  reasons 
behind  use  of  technology.  As  previously 


stated,  the  companies  assessed  had 
adopted  aggressive  business  practices. 
Further,  the  use  of  technology  was  not 
pursued  for  its  own  sake,  but  as  an 
enabler  to  achieve  the  business 
objective.”  A  statement  like  this  seems 
hannless  enough,  but  it  reveals  an 
attitude  toward  systems  technology  that 
has  hampered  the  progress  that  could 
have  otherwise  been  made.  The 
implication  is  that  system  technologists 
are  pushing  technology  for  their  own 
ends.  There  is  often  an  uneasy 
relationship  between  system-oriented 
and  process-oriented  personnel  at  the 
shipyards,  even  within  the  IT 
organizations.  The  process-oriented 
group  wants  to  give  the  impression  that 
the  only  real  successes  occur  when  the 
technology  is  “pulled”  by  them  rather 
than  “pushed”  by  the  technologists.  It  is 
not  unusual  for  deployments  of  new 
technology  to  fail,  but  the  reasons  for 
these  failures  are  usually  complex  and 
far-reaching,  sometimes  involving 
incidental  such  as  the  experience  of  the 
developers  and  sometimes  involving 
deeper  issues  such  as  misunderstanding 
of  technical  capabilities  and  limitations. 
Sometimes  the  reasons  are  not  technical 
at  all,  but  are  related  to  resistance  to 
change.  In  any  case,  it  is  rare  to  find  a 
shipyard  that  is  willing  to  invest 
resources  in  technology  for  technology 
sake.  This  controversy  hides  a  key  issue: 
at  shipyards  today  there  is  a  lack  of 
detailed  knowledge  of  the  capabilities 
and  limitations  of  systems  technologies. 
At  the  management  level  there  is  little 
opportunity  to  devote  the  effort  required 
to  make  sound  technical  judgments,  but 
even  at  the  IT  level  there  are  issues. 
Since  most  shipyards  have  adopted  a 
policy  of  outsourcing  systems 
technology  support,  systems  technology 
expertise  has  gradually  migrated  out  of 
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the  shipyards.  This  is  in  contrast  to  the 
situation  in  the  1970s  and  1980s  when 
the  larger  shipyards  used  their  own 
engineering  staffs  to  develop  the  first 
generation  CAE  and  CAD  applications. 
The  problem  with  this  situation  is  that,  in 
fact,  technology  does  not  respond  to 
process  drivers.  On  the  contrary,  the 
most  innovative  and  revolutionary 
process  improvements  come  only  after 
new  breakthroughs  in  systems 
technologies. 

The  CAD/CAM/CIM  evaluation  report 
also  says  that  the  shipyards  that  were 
most  successful  had  a  well-defined 
business  and  technology  plan  (including 
a  plan  for  sustaining  research  and 
development  activities).  This  was  the 
case  in  the  1990s  when  the  direction  at 
the  shipyards  was  clear:  migrate  the 
CAD  and  solid  modeling  so  that  product 
data  could  be  captured  once  and  re-used 
many  times.  The  strength  of  this  strategy 
was  that  it  was  concise  and  easily 
understood  by  everyone  involved.  Today 
the  situation  is  more  challenging.  The 
key  technical  issues  require  some 
technical  background  to  be  grasped,  and 
the  resulting  strategies  can  be 
complicated.  Under  these  conditions  it 
can  be  challenging  to  obtain 
management  support. 

The  goal  of  this  report  is  to  provide  a 
high-level  assessment  of  the  systems 
technologies  that  are  currently  available 
or  are  feasible  in  the  near  term.  This 
assessment  includes  a  description  of 
capabilities  as  well  as  limitations 
inherent  in  the  technologies.  It  also 
matches  technical  capabilities  to  current 
requirements.  The  report  avoids  a  bake¬ 
off  approach  of  comparing  particular 
vendors.  It  is  more  strategic  than  tactical. 
The  CAD/CAM/CIM  requirements 


identified  in  1997  are  still  valid,  and  they 
provided  the  groundwork  for  this  report. 
Those  requirements  were  mainly 
functional  in  nature;  this  report  also 
attempts  to  identify  the  non¬ 
requirements,  that  is,  the  implementation 
constraints  that  systems  technology  must 
respect.  Each  section  in  the  report  begins 
with  some  background  on  a  particular 
functional  area  and,  then,  describes  the 
current  state  of  the  technology  as  it 
relates  to  that  area.  The  focus  of  this 
report  is  an  assessment  of  systems 
technology  support  for  shipbuilding 
production  processes.  Therefore,  the 
background  section  provides  only  a 
thumbnail  overview  of  each  production 
process  area.  The  state  of  the  art  section 
addresses  in  detail  the  current  state  of 
the  art  for  systems  tech  for  that  area. 
Moreover,  each  section  ends  with  a 
discussion  of  the  opportunities  that  may 
be  applied  in  that  area.  Finally,  the 
report  concludes  with  a  summary  of 
these  opportunities  in  the  form  of  a  road 
map  for  future  development. 

II.  Systems  Technology  Areas  of 
Investigation 

1.  Improved  Definition  of  the  Product 
Model  to  Capture  Manufacturing  Data 

a.)  Current  CAD  Capabilities 

Background 

This  section  describes  the  requirements 
and  capabilities  of  computer-aided 
design  (CAD)  and  Product  Data 
Management  (PDM)  systems  with 
respect  to  shipbuilding  production 
processes.  CAD  and  PDM  systems  are 
the  key  elements  of  the  shipbuilding 
integrated  development  environment 
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(IDE).  They  support  the  creation  and 
configuration  management  of  the  design 
and  engineering  work  products  for  the 
ship.  As  such,  the  influence  they  have  on 
production  process  is  significant  but 
indirect. 

A  shipyard’s  Integrated  Development 
Environment  is  comprised  of  a 
combination  of  CAD,  CAE  and  PDM 
application  services.  In  the  mid-1980’s 
Litton  Ingalls  Shipbuilding  (now 
Northrop  Grumman  Ship  Systems) 
implemented  Calma  3D  System  (now 
PTC’s  Dimension  III).  In  the  1990’s  the 
first  tier  U.S.  shipyards  migrated  to  3D 
CAD  tools  (at  first  homegrown  and  later 
customized  COTS).  This  generation  of 
CAD  tools  was  driven  by  the 
requirement  to  minimize  the  creation 
and  management  of  product  model  data. 
The  goal  was  to  capture  the  product 
design  data  once  and  re-use  it  many 
times.  This  entails  a  change  from  a  2D 
drawing  oriented  view  to  a  3D  product 
model  view.  In  most  shipyards  this 
migration  was  overseen  by  the 
engineering  department  and  as  part  of 
the  migration,  the  myriad  of  CAE  tools 
were  also  interfaced  with  the  new  CAD 
platform.  The  goal  of  extensive  re-use 
cannot  be  realized  without  effective 
configuration  management  -  keeping 
track  of  which  versions  of  the  product 
model  files  were  associated  with  which 
downstream  application.  This 
requirement  was  addressed  by  the 
introduction  of  PDM  systems. 

In  the  areas  of  CAD  and  PDM,  however, 
the  shipbuilding  industry  found  itself  in 
an  unfortunate  position.  The  information 
requirements  for  ships  are  much  more 
challenging  than  the  information 
requirements  for  automobiles  or  aircraft, 
yet  the  shipbuilding  industry  represented 


only  a  small  portion  of  the  market  share 
for  CAD  and  PDM  vendors.  A  naval 
combatant  (carrier  or  submarine) 
consists  of  2  to  4  million  piece  parts;  an 
automobile  consists  of  about  15K  parts; 
and  an  aircraft  250K  parts.  Moreover, 
for  every  dollar  the  shipbuilding  industry 
spends  on  CAD/PDM,  the  aerospace 
industry  spends  ten  dollars,  and  the 
automotive  industry  spends  $20.  The 
disparity  is  striking,  and  it  is  only  natural 
that  the  CAD  and  PDM  vendors  would 
respond  more  enthusiastically  to  the 
customers  with  simpler  requirements  and 
more  money.  The  end  result  is  that  CAD 
and  PDM  systems  are  developed,  first 
and  foremost,  in  response  to  the 
requirements  of  the  automotive  and 
aerospace  industries.  The  shipbuilding 
requirements  that  are  above  and  beyond 
the  basic  functionality  are  not  addressed 
in  the  standard  COTS  offering.  Those 
requirements  are  met  either  by 
customization  done  by  the  shipyard  itself 
or  by  enhancements/accelerated 
development  done  by  the  CAD/PDM 
vendor  but  underwritten  by  the  shipyard 
or  its  customer.  A  specific  example  is 
the  Department  of  the  Navy  (DoN)  has 
invested  several  million  dollars  in  the 
development  of  Dassault  Systemes’ 
CAD  product  (CATIA)  in  support  of  the 
current  destroyer  acquisition  program 
DD(X).  The  goal  of  the  investment  is  to 
have  needed  shipbuilding  functionality 
incorporated  into  the  CAD  platform.  On 
top  of  the  investment,  the  DoN  and 
participating  shipyards  will  then  have  to 
buy  the  software  licenses  to  use  the 
product  they  paid  to  have  developed. 

State  of  the  art 

Most  people  in  ship  design  and 
engineering  community  understand  the 
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capabilities  of  CAD  and  solid  modeling. 
They  recognize  the  differences  between 
producing  engineering  drawings  and 
CAD  models.  However,  even  among 
shipbuilding  designers  and  engineers, 
there  is  still  a  lot  of  confusion  about  the 
role  of  PDM  systems.  One  reason  for  the 
confusion  is  the  PDM  systems  on  the 
market  today  were  designed  to  support 
the  processes  of  the  automotive  and 
aerospace  industries.  Users  in  the 
shipbuilding  world  have  difficulty 
mapping  the  functionality  of  the  PDM 
system  to  the  requirements  of  their  own 
design  processes.  Traditional  PDM 
systems  emerged  from  the  need  to 
manage  product  model  data  so  that  it 
could  be  created  once  and  re-used  many 
times.  The  way  PDM  systems  address 
this  challenge  is  that  the  master  copy  of 
the  product  model  is  stored  in  a  secure 
datastore  (sometimes  referred  to  as  a 
‘vault’),  where  its  data  integrity  can  be 
protected  and  where  changes  can  be 
tracked  and  controlled.  Users  only  deal 
with  copies  of  the  vaulted  data.  There  is 
a  notion  of  check-in  and  check-out  as 
users  reserve  the  right  to  edit  or  to  view 
the  data.  Only  one  user  at  a  time  has  the 
right  to  change  the  product  data.  Today’s 
production  PDM  systems  are  built 
around  the  notion  of  documents,  and  the 
primary  type  of  document  is  the  CAD 
model  file.  Accordingly,  these  PDM 
systems  manage  data  at  the  model  level. 
The  other  major  functions  of  the  PDM 
system  include  the  association  of 
attributes  to  the  CAD  models,  the 
management  of  other  electronic 
documents  (in  the  vault)  and  the 
association  of  documents  to  other 
documents.  The  PDM  system  provides 
configuration  management  of  the 
documents,  keeping  track  of  versions 
and  effective  application  to  versions  of 
documents.  As  part  of  its  data 


management  function,  the  PDM  system 
provides  the  means  to  classify 
information.  Documents  of  similar  types 
can  be  grouped  together  in  named 
classes.  One  important  grouping  is  the 
engineering  bill  of  material,  which 
describes  the  as-design  product  structure 
of  the  models  as  they  are  organized  as 
components  and  assemblies. 

One  of  the  major  deficiencies  of  today’s 
PDM  systems,  with  respect  to 
shipbuilding  requirements,  is  that  the 
PDM  systems  manage  data  at  the  model 
(or  document)  level.  However,  ship 
design  and  construction  requires  the 
management  of  data  at  the  piece  part 
instance  level.  Typically,  a  CAD  model 
of  piping  or  structural  system  contains 
hundreds  of  parts,  but  the  traditional 
PDM  system  just  manages  the  model 
itself.  The  PDM  attributes  apply  to  the 
model  per  se;  there  is  no  mechanism  for 
managing  attributes  for  each  instance  in 
the  model.  The  same  holds  for  the  PDM 
functions.  For  ship  design,  it  is  the 
instances  that  must  be  organized  in  a 
product  structure.  Each  instance  must 
also  be  configuration  managed, 
effectively  assigned,  and  linked  to  its 
associated  documents.  This  shortcoming 
is  closely  related  to  the  design  of  the 
CAD  system.  The  first-generation  CAD 
systems  were  also  model-based.  The 
CAD  model  was  the  unit  of 
functionality.  In  the  early  CAD  systems 
the  constituent  items  that  made  up  a 
model  were  not  even  given  permanent 
identifiers.  These  transient  identifiers 
would  change  each  time  the  model  was 
opened.  This  improved  the  processing 
speed,  but  made  it  impossible  to 
accomplish  any  data  management  of 
items  within  a  model.  By  the  same 
token,  the  first  generation  PDM  systems 
adopted  the  philosophy  that  one  model 


corresponds  to  one  single  part.  This 
philosophy  works  for  the  design  of 
mechanical  products,  but  not  for 
shipbuilding.  The  second  generation 
integrated  product  development 
environment  (IPDE)  systems  are 
currently  in  place  at  the  first  tier 
shipyards.  The  most  important  new 
characteristic  of  these  systems  is  that 
they  manage  instances,  as  well  as 
models.  However,  these  systems  had  to 
be  custom  built  for  the  shipbuilding 
industry  -  either  by  the  shipyard  itself  or 
as  a  special  development  executed  by  the 
CAD  vendor  and  funded  by  the 
shipyard. 

For  the  last  few  years  the  nature  of  the 
CAD  data  itself  has  been  a  major 
concern  for  CAD  vendors.  Partly 
motivated  by  complaints  from  the 
shipbuilding  industry,  but  also  driven  by 
the  need  to  improve  CAD  capabilities 
for  other  industries,  the  CAD  vendors 
have  been  exploring  ways  to  manage 
CAD  data  at  the  piece  part  rather  than 
the  model  level.  The  first  avenue  that 
was  pursued  was  the  notion  of  exploding 
the  model.  A  model  would  represent  a 
session  from  the  user’s  perspective,  but 
when  the  model  is  saved  it  would  be 
exploded  into  its  constituent  pieces,  and 
each  piece  would  be  stored 
independently  in  the  CAD  database. 
When  the  model  was  re-opened,  the 
pieces  would  be  re-assembled.  Progress 
with  this  approach  has  been  slow 
especially  for  models  of  the  size  found 
in  shipbuilding.  The  issues  involve 
access  perfonnance  as  well  as  the 
difficulty  of  managing  the  relationships. 
Independently,  the  infonnation 
technology  industry  has  been  pursuing  a 
similar  problem  from  a  different 
direction.  The  management  of 
information  within  structured  documents 


is  an  analogous  problem.  The  document 
itself  is  the  primary  container  for  its 
constituent  parts,  yet  there  is  usually  a 
need  to  access  the  parts  of  the  structured 
document  by  themselves.  Using  XML 
technology,  the  approach  has  been  to 
“expose”  the  contained  items.  That  is,  it 
is  possible  to  access  individual 
component  items  even  though  the 
document  is  still  managed  as  a  whole. 
There  are  benefits  to  this  approach;  there 
is  a  cohesion  to  a  CAD  model  or  a  to  a 
document.  More  often  than  not,  the 
model/document  is  accessed  and  used  in 
its  entirety.  The  ability  to  access 
individual  elements  is  a  secondary 
requirement  and  should  not  be  enabled  at 
the  expense  of  this  capability. 

The  second  deficiency  of  the  today’s 
PDM  systems  is  in  the  area  of 
configuration  management.  Management 
of  the  configuration  and  effectiveness 
are  expected  capabilities  of  a  PDM 
system.  However,  in  today’s  systems 
these  capabilities  have  been  designed 
primarily  in  support  of  automotive 
industry  requirements.  Many  PDM 
systems  have  extensive  configuration 
management  modules,  which  manage 
options  and  variants.  In  some  systems 
configuration  management  of  options 
and  variants  are  even  controlled  by 
design  rules.  For  shipbuilding 
applications,  managing  effectiveness 
takes  the  form  of  hull  applicability.  The 
capability  to  manage  options  and 
variants  is  non-value-added  overhead. 
Moreover,  as  with  shipbuilding  CAD, 
shipbuilding  PDM  needs  to  manage 
instances.  Typical  PDM  systems  manage 
parts  only.  A  part  may  have  any  number 
of  occurrences  within  a  product.  An 
instance  is  a  single  occurrence  of  a  part 
at  a  particular  location  in  the  product. 
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Finally,  an  important  aspect  of 
shipbuilding  product  data  is  the 
management  of  joints  (or  connectivity) 
between  instances  in  the  product.  These 
may  be  structural  as  well  as  piping 
joints.  Today’s  PDM  systems  do  not 
emphasize  this  capability,  and 
shipbuilders  are  left  to  custom  develop 
the  code  to  manage  joint  data.  This 
capability  should  be  part  of  the  PDM 
system. 

Opportunities 

CAD /PDM  system  enhancements  (e.g., 
instance  management) 

The  opportunities  in  the  CAD/PDM 
arena  depend  predominantly  on  the 
business  cases  of  the  technology 
vendors.  The  shipbuilding  industry 
should  however,  make  improvements  to 
the  definition  of  its  requirements.  As  we 
have  seen  ship  design  and  construction 
requirements  are  very  complex  and  are 
often  interwoven  with  confusing 
technical  details.  Today  requirements  are 
conveyed  to  the  CAD  vendors  by 
individual  shipyards  or  individual 
programs.  There  should  be  a  great  effort 
within  the  industry  to  define  the  core 
requirements  that  are  needed  to  support 
the  ship  design  and  construction 
processes.  These  requirements  must 
include  remedies  for  the  deficiencies 
described  above:  instance-management, 
shipbuilding-specific  configuration 
management  (hull  applicability),  and 
management  of  joints. 


Feature-based  design 

The  first  generation  of  IPDE  systems 
among  U.S.  shipbuilders  was  devoted 


largely  to  the  migration  from  2D 
drawings  to  3D  product  models.  The  3D 
models  employed  the  new  technologies 
for  solid  modeling.  To  a  lesser  extent, 
some  of  the  discipline-specific  CAD 
applications  employed  a  feature-based 
approach.  However,  there  is  no 
comprehensive  feature-based  design 
capability  in  place  among  the  first  tier 
shipyards.  The  availability  of  feature- 
based  design  product  model  is  a  pre¬ 
requisite  to  the  automation  of  many 
shipbuilding  production  processes.  This 
issue  is  explored  in  more  detail  below. 

CAD/PDM  data  sharing 

Most  of  the  work  in  the  area  of 
CAD/PDM  data  sharing  originates  with 
the  STEP  standard.  The  Standard  for  the 
Exchange  of  Product  model  data  (STEP) 
is  the  international  standard,  ISO  10303. 
It  consists  of  a  voluminous  series  of 
documents,  which  provide  different 
industries  with  the  capability  to 
exchange  and  share  the  information  that 
defines  a  product  model.  Such 
information  sharing  may  be  between 
shipbuilders  or  among  systems  within  a 
shipyard.  This  product  data  is  designed 
to  support  the  entire  product 
development,  life  cycle.  Today  the  first 
set  of  shipbuilding  specific  application 
protocols  are  being  completed  and 
adopted.  The  first  generation  standards 
focus  on  an  explicit  geometric 
representation  of  the  product.  There  is 
some  attempt  to  capture  design  features 
in  these  models,  but  it  is  not 
comprehensive.  As  described  in  more 
detail  below,  the  next  generation 
information  model  needs  to  be  able  to 
capture  shipbuilding  specific  design 
features  that  can  be  related  to  the 
appropriate  manufacturing  features. 
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b.)  Shipbuilding  product  models, 
drawings  and  STEP-NC 

Background 

This  section  describes  the  state  of  the  art 
of  product  modeling  for  the  shipbuilding 
industry,  particularly  as  it  relates  to 
production  processes.  One  of  the  major 
software  tools  used  today  in  the  U.S.  is 
Tribon  where  in  Europe  and  Asia,  a 
popular  tool  is  Hicadec. 

Most  U.S.  shipyards  have  recently 
completed  a  migration  in  product 
modeling  capabilities  from  systems  in 
which  the  engineering  drawing  was  the 
primary  work  product  to  systems  in 
which  a  digital  3D  product  model  is  the 
primary  work  product.  This  migration 
represents  a  significant  investment  and  is 
built  on  the  premise  that  the  CAD 
product  model  can  be  re-used  in  many 
downstream  applications.  Because  its 
market  share  is  limited,  the  shipbuilding 
industry,  for  the  most  part,  has 
accomplished  the  migration  using  CAD 
systems  that  were  developed  in  response 
to  the  requirements  of  other  industries. 
The  first  generation  migration  consisted 
of  the  capturing  of  explicit  solid 
geometry  representations.  However, 
geometry  by  itself  does  not  constitute  a 
product  model.  For  example,  a  purely 
geometric  model  can  appear  on  the 
screen  to  be  the  model  of  a  piping 
system  without  actually  having  the 
characteristics  of  a  product  model.  The 
cost  justification  of  creating  a  product 
model  is  that  it  will  be  re-used  again  and 
again  by  downstream  users  and 
applications  as  well  as  systems. 
Nevertheless,  virtually  all  shipyards  are 
still  producing  2D  drawings  in  addition 
to  the  CAD  product  model.  In  fact,  in 
most  cases  the  CAD  system  is  used  as 


the  means  for  generating  the  engineering 
drawing.  However,  the  engineering 
drawing  is  more  than  just  a  published 
view  of  the  product  model.  Engineering 
drawings  still  capture  information  that  is 
not  captured  anywhere  in  the  product 
model. 

State  of  the  art 

The  rationale  for  the  migration  to  3D 
CAD  systems  was  the  ability  to  create  a 
complete,  product  model  that  could  be 
captured  once  and  used  many  times.  The 
adoption  of  solid  modeling  of  nominal 
geometry  is  only  the  first  step  in  the 
process  of  enabling  this  capability.  The 
first  generation  CAD  platforms  adopted 
by  the  shipbuilding  industry  placed  a 
heavy  emphasis  on  tools  to  create  and 
edit  solid  geometry.  This  was  a  natural 
evolution  since  solid  modeling 
technology  was  just  coming  to  maturity 
during  that  time,  and  CAD  vendors  were 
focusing  most  of  their  resources  on  that 
technical  challenge.  However,  capturing 
the  nominal  solid  geometry  is  only  the 
first  step  in  the  definition  of  a  re-usable 
product  model.  Raw  geometry  becomes 
re-usable  after  it  has  been  associated 
with  design  features.  A  feature  is  a  data 
entity,  which  represents  specific 
meaning  with  respect  to  a  product.  It  is  a 
user-oriented  aspect  or  characteristic 
within  a  product  model.  The  definition 
of  features  is  related  to  the  object- 
oriented  approach  for  information 
modeling.  With  more  meaning  captured, 
it  becomes  easier  for  later  applications  to 
re-use  the  product  model.  Features  are 
closely  related  to  parametric  modeling. 
Features  are  instantiated  by  assigning 
actual  values  to  one  or  more  variable 
parameters.  In  addition,  constraints  are 
used  to  specify  relationships  between 
features  and  feature  parameters. 
Together,  features  and  constraints  begin 
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to  define  the  design  intent  behind  the 
product  model.  Moreover,  with  feature- 
based  systems,  better  definition  of  the 
product  model  is  available  facilitating 
the  use  of  Group  Technology. 

The  first  generation  of  feature-based 
design  tools  focused  on  geometric 
features.  The  earliest  systems  supported 
the  ability  to  generate  families  of  shapes 
from  a  2D  profile  and  designated 
parameters.  This  capability  supported 
mainly  mechanical  design  scenarios.  In 
the  shipbuilding  industry,  these 
parametric  systems  have  been  used  in 
the  conceptual  design  process,  in  which 
the  ability  to  do  what-if  analyses  is 
important. 

The  first  major  value-add  of  feature- 
based  modeling  is  its  ability  to  capture 
design  intent.  Design  intent  is  missing  in 
CAD  systems  that  support  only  solid 
geometric  modeling.  Furthermore,  even 
though  some  systems  support  feature- 
based  modeling,  that  information  is 
typically  lost  in  the  process  of  data 
exchange  because  feature-based 
exchange  capabilities  are  not  widely 
supported  by  CAD  vendors.  A  feature- 
based  representation  augments  the 
geometric  model  with  a  representation  of 
design  freedom,  geometric  constraints 
and  design  features.  Design  freedom 
indicates  the  range  of  allowable  design 
alternatives.  Geometric  constraints  make 
explicit  the  limitations  imposed  on  the 
allowable  design  alternatives.  Geometric 
constraints  include  such  characteristics 
as  parallelism,  perpendicularity, 
symmetry,  and  tangency.  Design 
features  are  high-level  design  constructs 
with  parameterized  dimensions.  They 
support  the  definition  of  families  of  parts 
in  which  dimensions  may  depend  on 


other  (possibly  non-geometric) 
parameters. 

The  development  of  international 
standards  for  sharing  geometric  features 
has  lagged  behind  the  implementation  of 
feature-based  CAD  platforms.  This  is 
understandable  since  features  are  largely 
user-oriented  constructs,  which  require  a 
degree  of  customization.  The  richness  of 
a  set  of  features  is  a  competitive 
advantage  for  a  given  feature-based 
CAD  platfonn.  Nevertheless,  in  the 
STEP  community,  ISO  10303- 108  is 
under  development.  It  provides  a 
standard  mechanism  for  associating 
parameters  with  model  dimensions  (and 
with  other  variables).  It  also  supports  the 
representation  of  geometric  constraints 
and  describes  how  to  associate  them 
with  geometric  elements.  Finally,  it 
supports  the  ability  to  model  complex 
shapes  based  on  2D  profiles. 

Another  major  value-add  of  feature- 
based  modeling  concerns  the  handoff  of 
the  product  model  from  design  to 
support  production  processes.  After  a 
design  product  model  is  complete, 
computer-aided  manufacturing  (CAM) 
and/or  computer-aided  process  planning 
(CAPP)  applications  can  be  used  to  add 
manufacturing  features.  Manufacturing 
features  need  to  be  kept  separate  from 
design  features.  Manufacturing  features 
provide  the  meaningful  constructs  that 
describe  how  to  manufacture  the 
product;  they  may  change  for  different 
manufacturing  facilities  or  for  other 
reasons  and,  thus,  should  not  be 
intermingled  within  the  design  product 
model.  As  with  design  features  there  is 
not  yet  a  standard  set  of  manufacturing 
features.  A  harmonized  set  of 
manufacturing  features  is  required  to 
support  interoperability  not  only 
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between  CAM  systems  at  different 
shipyards  but  also  between  CAD  and 
CAM  systems.  The  lack  of 
interoperability  between  CAD  and  CAM 
systems  is  costly.  Today,  in  many  cases, 
the  loading  of  the  CAM  system  involves 
costly  data  conversions, 

misinterpretations  of  meaning  and 
errors,  which  may  result  in  lost  time  and 
costly  rework. 

The  STEP-NC  standard  is  under 
development;  it  will  address  the 
interoperability  of  CAD,  CAM  and  CNC 
systems.  In  today’s  environment 
machines  on  the  shop  floor  are  populated 
with  information  that  is  conveyed  in  two 
steps.  The  first  step  is  the  construction  of 
the  CAM  or  CAPP  model,  which  begins 
with  nominal  geometry  from  a  CAD 
system.  That  geometry  can  be  in  a 
standard  format  such  as  IGES,  APT  or 
STEP.  However,  the  exchange  of  design 
features  is  virtually  unsupported.  The 
final  product  specification  is  still 
conveyed  by  means  of  2D  engineering 
drawings.  The  product  specification  is 
the  information,  which,  together  with 
nominal  geometry,  describes  how  the 
product  is  to  be  produced.  The  second 
step  entails  the  transfer  of  the  CAM 
model  to  the  CNC  machines  -  at  least 
for  those  production  processes  that  can 
be  automated.  Today  this  data  transfer  is 
nearly  always  accomplished  using  the 
part-programming  standard,  ISO  6983, 
which  is  also  known  as  the  M&G  code. 
This  standard  was  developed  about  forty 
years  ago.  Even  though  it  has  the  benefit 
that  it  actually  works,  the  M&G 
interface  often  proves  to  be  a  bottleneck. 
M&G  code  is  produced  by  means  of  a 
post-processor,  usually  implemented  in 
the  CAM  system.  While  the  CAM  model 
consists  essentially  of  geometric  and 
manufacturing  features,  the  M&G  file 


contains  only  low-level  instructions  that 
guide  the  movement  of  the  CNC 
machines.  Of  course,  each  machine  has 
its  own  capabilities  and  specialties,  and 
for  full  compatibility  these  extensions 
need  to  be  incorporated  in  the  CAM 
system.  Newer  machine  tools  have  more 
capabilities  and  more  opportunities  for 
optimization;  in  fact,  it  may  be  possible 
to  adjust  the  process  plan  based  on 
feedback  from  the  machine  itself. 
However,  data  flow  in  this  environment 
is  only  one  way.  Since  the  process  plan 
is  generated  in  the  CAM  system,  it  is 
impossible  to  take  advantage  of  such 
potential  optimizations. 

The  technical  approach  embodied  in  the 
STEP-NC  standard  is  to  develop  an 
integrated  data  model  (encompassing 
CAD,  CAM,  CAPP  and  CNC 
functionality).  The  integrated  data  model 
includes  geometry  (CAD),  features  (both 
design  and  manufacturing),  and  tool 
definitions  (including  both  the  geometric 
configuration  of  the  tool  as  well  as  its 
technological  information).  The  purpose 
of  the  integrated  product  model  is  to 
provide  enough  information  to  support 
the  intelligent  generation  of  the  tool 
paths  needed  to  manufacture  the  part 
given  the  available  manufacturing  tools. 
This  includes  not  only  the  geometry  of 
the  tool  path,  but  speeds  and  feeds  as 
well.  The  work  plan  can  then  be 
optimized  based  on  the  individual 
machine  and  potentially  based  on 
feedback  from  the  operating  conditions 
of  the  machine  itself.  The  STEP-NC 
product  model  begins  with  the  nominal 
geometry  (and  design  features)  from  the 
CAD  product  model  and  represented  in 
STEP  form.  The  CAM  system,  then, 
enhances  this  model  by  associating  it 
with  manufacturing  features,  such  as 
pockets,  borings  and  grooves.  In 
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addition,  the  technological  data  for  each 
machine  is  represented  through  available 
operations  and  tool  constraints.  Finally, 
a  working  plan  is  captured,  which  is  a 
description  of  each  working  step  that 
must  be  performed.  The  working  plan 
designates  what  needs  to  be  done,  not 
how  it  is  to  be  done.  The  intelligent 
manufacturing  model,  then,  consists  of 
the  combination  of  the  working  plan, 
nominal  geometry,  manufacturing 
features  and  tool  descriptions.  From  this 
information,  a  CNC  controller  can 
employ  its  own  algorithms  to  define  the 
low-level  operations  that  best  execute 
the  plan.  The  integrated  model  would  be 
the  same  for  all  compliant  controllers 
and  represents  a  more  complete  and 
computer-interpretable  product 

specification.  As  a  fall  back,  the  standard 
also  supports  the  explicit  representation 
of  the  tool  path.  Currently,  the  STEP-NC 
standards  community  is  focusing  on 
models  for  milling  and  turning. 

The  STEP-NC  effort  began  with  a 
definition  of  the  user  requirements  for 
turning  and  milling  as  part  of  ISO 
14649.  This  work  has  been  harmonized 
with  the  STEP  standard  in  ISO  10303- 
238,  the  application  protocol  for  STEP- 
NC.  This  standard  defines  the  interface 
between  CAM  manufacturing  features 
and  CNC  systems.  It  also  provides 
information  interoperability  with  the 
nominal  geometry  defined  in  the  CAD 
model. 

Although  the  technical  approach  of  the 
STEP-NC  work  shows  promise  for  the 
shipbuilding  industry,  the  usefulness  of 
the  current  activities  is  limited.  Milling 
and  turning  processes  play  a  minor  role 
in  the  shipbuilding  process.  The  most 
pressing  areas  for  manufacturing  in  the 
shipbuilding  industry  are  in  the 


specialized  areas  of  structures  and 
piping.  The  STEP-NC  approach  is  well 
suited  to  these  areas,  particularly  as 
means  for  automating  the  manufacturing 
processes  and  the  CAD  to  CAM/CNC 
interfaces.  The  requirements  and  state- 
of-the-art  for  structural  and  piping 
manufacturing  processes  are  described  in 
detail  below. 

There  is,  however,  a  more  general 
problem  facing  the  shipbuilding 
industry.  Shipbuilding  product  processes 
are  not  limited  to  manufacturing 
processes;  in  fact,  shipbuilding  is  largely 
an  assembly  and  outfitting  process.  With 
today’s  technology  there  is  still  a  need 
for  better  support,  from  the  digital 
product  model,  for  assembly  and 
outfitting.  In  U.S.  shipyards  today,  2D 
CAD  platforms  continue  to  flourish, 

even  though  most  of  the  shipyards  have 
already  adopted  3D  CAD  platfonns  and 
make  extensive  use  of  3D  product 

models.  Even  though  they  have 

increased  utility,  3D  product  models  are 
expensive  to  build.  They  are  more 
expensive  than  simply  using  computer- 
aided  drafting  tools.  The  current 

situation  is  that  the  3D  CAD  model  is 
used  as  the  means  to  help  generate  the 
2D  engineering  drawing.  The  2D 
engineering  drawing  is  still  the  primary 
means  of  disclosing  the  product  model 
and  product  specification.  Often  the 
drawings  are  printed  and  distributed  in 
paper  fonn,  but  demand  for  this 
information  is  so  great  that,  in  some 
cases,  the  drawing  itself  is  distributed  in 
digital  fonn  as  a  raster  image.  The  raster 
image  is  a  dumb  reproduction  of  the 
drawing;  it  carries  no  computer- 
interpretable  information.  Nevertheless, 
the  engineering  drawing  is  the  primary 
tool  used  both  for  construction  and  post¬ 
delivery  support. 
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The  biggest  problem  with  the 
engineering  drawing  is  its  strength  as  a 
means  of  communicating  the  complete 
product  specification.  The  drawing  is 
easily  understood  by  human  users  and  is 
the  only  place  in  which  the  complete 
product  specification  can  be  found.  The 
engineering  drawing  is  able  to  convey 
the  product  specification  information  for 
assembly  and  outfitting  that  is  missing 
from  the  product  model.  In  today’s 
systems  the  3D  CAD  product  model, 
which  consists  largely  of  nominal 
geometry,  does  not  contain  all  the 
information  needed  to  realize  the 
product.  These  requirements  include  the 
nominal  geometry  of  the  product,  the  3D 
product  model  (discipline-specific)  and 
the  product  specification.  The  product 
specification  infonnation  includes  such 
things  as  critical  dimensions  and 
tolerances.  The  product  model  provides 
an  infinite  number  of  dimensions; 
however,  only  a  small  number  of 
dimensions  are  critical  for  manufacture 
and  assembly.  Today’s  3D  product 
models  do  not  have  the  means  to 
designate  which  dimensions  are  critical. 
Similarly,  tolerances  need  to  be 
associated  with  the  critical  dimensions, 
and  today  this  is  done  only  in  the 
engineering  drawing. 

Problems  arise  when  the  3D  product 
model  is  used  as  the  means  to  generate 
the  2D  engineering  drawing.  Essentially, 
the  product  model  and  the  drawing  are 
two  different  views  of  the  same  design 
in  two  different  formats.  The 
engineering  drawing  is  a  complete 
product  specification,  but  it  is  not 
computer-interpretable.  Even  though  its 
information  can  be  readily  understood 
by  human  users,  it  cannot  be  re-used  by 
downstream  applications.  Each  view  of 
the  design  must  be  maintained 


separately,  and  the  danger  exists  that 
they  could  get  out  of  synch.  The 
shipbuilding  product  is  characterized  by 
a  very  large  quantity  of  piece  parts, 
which  change  substantially  over  a  long 
period  of  time.  The  configuration 
management  requirements  are  more  than 
doubled  by  such  a  dual  representation. 
The  result  is  a  significant  non-value- 
added  step  in  the  ship  design  process. 
The  engineering  drawing  needs  to  be 
checked  for  consistency  and  accuracy. 
Even  in  shipyards  that  make  extensive 
use  of  the  3D  product  model,  most 
checking  is  still  done  with  respect  to  the 
drawing.  In  addition,  the  drawing  itself 
needs  to  be  developed  and  published. 
The  drawing  consists  in  part  of 
information  generated  from  the  CAD 
product  model  (selected  views)  and  in 
part  of  information  that  is  transcribed 
and  captured  only  in  the  drawing. 
Without  one  single  computer- 
interpretable  representation  of  the 
product  model  and  product  specification, 
advanced  automation  of  the  related 
shipbuilding  production  processes 
cannot  be  realized. 

Opportunities 

Digital  product  specification 

One  of  the  foremost  opportunities  for 
improved  production  processes  is  the 
ability  to  create  a  complete  product 
model  and  product  specification,  in 
computer-interpretable  form,  in  one 
system  (possibly  modular  or  distributed). 
There  are  several  pre-requisites  to  such  a 
capability.  First,  there  is  the  need  for  a 
standard,  feature-based  representation 
for  each  of  the  design  disciplines  used  in 
shipbuilding.  Work  on  such  a  standard  is 
well  under  way  with  the  STEP 
shipbuilding  application  protocols  (AP). 
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These  standards  will  cover  ship 
structures,  piping,  HVAC  and 
arrangements.  User’s  guides  have  been 
developed  to  use  AP212, 
Electrotechnical  Design  and  Installation. 
AP226  Ship  Mechanical  Systems  is 
currently  under  review.  New  AP 
development  areas  that  should  be 
addressed  include  outfit  and  furnishings, 
electronics  and  mission  systems.  The 
second  pre-requisite  is  support  for  the 
standard  product  data  model  among 
CAD  system  vendors.  This  entails  not 
merely  the  translators  for  the  exchange 
of  the  product  model  but  also  the 
functional  capabilities  to  create  and  edit 
the  shipbuilding-specific  product 
models.  The  next  pre-requisite,  then,  is 
the  ability  to  model  tolerances,  critical 
dimensions  and  the  rest  of  the  product 
specification  information  needed  to 
manufacture,  assemble  and  construct  the 
product.  The  next  pre-requisite  is  the 
definition  of  the  manufacturing  features 
(and  other  STEP-NC  constructs)  needed 
to  interface  with  automated 
manufacturing  tools.  These  features 
must  cover  all  the  shipbuilding  trades. 
The  final  prerequisite  is  the  system 
technology  for  accumulating  and 
publishing  an  integrated  product  model 
and  product  specification.  In  order  to  be 
successful,  this  technology  must  be 
perceived  as  a  satisfactory  replacement 
for  the  engineering  drawing  among  all 
users  of  drawings,  and  it  must  present  a 
computer-interpretable  product 

model/specification  that  can  be  re-used 
by  other  applications. 


2.  Fabrication 
a.)  Steel 
Background 

This  section  describes  the  systems 
technologies  that  support  the  lofting  and 
nesting  processes  for  steel  processing. 
These  processes  depend  upon  design 
product  model  data;  however,  the  lofting 
and  nesting  processes  are  actually  CAM 
processes.  These  processes  begin  at  the 
release-for-production  of  the  design 
product  model  and  end  with  an 
individual  cut  part,  prior  to  its  use  in  an 
assembly  or  its  installation  on  the  ship. 
The  NSRP  Benchmarking  Report 
NSRP[2001]  found  that  for  world-class 
overseas  shipyards  lofting  and  nesting 
are  for  the  most  part  integrated  with 
engineering  processes  -  having  replaced 
manual  lofting  and  template  making.  In 
the  U.S.  all  yards  now  use  computer- 
aided  lofting  and  nesting  systems  that 
are  derived  from  a  CAD  model.  The 
report  adds  that,  ’’Many  of  the 
procedures  would  be  world-class  if  there 
were  direct  links  to  NC  cutting  and 
forming  machinery  and  if  a  structured 
method  of  detennining  shrinkage 
allowances  was  in  place  using  data  that 
had  been  produced  from  statistical 
process  control.”  In  other  words  there  is 
room  for  much  more  automation  than  is 
found  today. 

Lofting  and  nesting  support  the 
manufacture  of  individual  plate  parts.  A 
structural  part  is  a  piece  part  that  is 
fabricated  from  raw  stock,  mainly  by 
cutting.  It  may  be  in  the  form  of  plate 
(flat  or  formed);  corrugated  material;  or 
profile.  A  corrugated  structural  part  is 
made  from  corrugated  stock  material.  A 
profile  structural  part  is  made  from 
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material  that  is  extruded  based  on  a  two- 
dimensional  cross-section.  The 
manufacture  of  profde  parts  is  supported 
today  primarily  by  means  of  drawings 
and  sketches.  Plate  is  made  from  flat 
shaped  stock  material,  which  is 
nominally  planar  in  shape.  A  formed 
plate  part  is  modified  by  a  bending 
operation  after  it  has  been  cut.  Up  until 
the  time  that  plate  is  formed,  it 
participates  in  the  lofting  and  nesting 
process  just  as  a  flat  plate  would.  The 
overall  lofting  and  nesting  process  is 
illustrated  in  Figure  1 : 


Figure  1:  Lofting  and  Nesting 
Lofting 

For  shipbuilding  applications  lofting  is 
the  process  of  defining  a  single  piece  to 
be  cut  from  flat  stock  material.  Lofting  is 
in  many  respects  a  flat  pattern  process, 
most  of  which  can  be  solved  using  two- 
dimensional  representations  and  rules.  In 
terms  of  the  computerized  machine 
control  systems,  however,  the  end  result 
is  a  2- U  D  process.  The  cutter  can  move 
in  the  x  and  y  directions  and  also  in  z, 
but  not  at  the  same  time.  Moreover,  the 
complete  definition  of  the  lofted  piece 
may  include  bevels  on  the  edges,  which 
introduce  a  3D  component  to  the 
process. 


Structural  parts,  such  as  plate  parts,  are 
designed  in  context  in  3D  CAD  systems. 
Individual  parts  are  managed  as 
components  within  a  larger  construct. 
There  are  typically  many  parts  in  a 
structural  product  model.  Moreover,  the 
CAD  model  locates  each  structural  part 
in  relationship  to  its  end  use.  The  CAD 
model  describes  not  only  how  it  is 
related  to  other  structural  parts  within  an 
assembly,  but  also  how  it  is  located  and 
oriented  with  respect  to  its  final 
installation.  A  great  deal  of  this 
infonnation  is  superfluous  when  the 
objective  is  to  manufacture  the  plate 
part.  In  the  CAD  model  the  part  is 
represented  as  a  solid;  in  the  lofting 
process,  a  two-dimensional  outline  (with 
some  parameters)  is  sufficient.  In  the 
CAD  model,  the  part  is  located  in  3D 
space;  in  the  lofting  process,  the  part 
needs  only  to  be  located  in  a  two- 
dimensional  manufacturing  space.  When 
the  source  of  the  design  data  is  a  paper 
drawing,  the  lofting  process  adds 
infonnation.  When  the  source  of  the 
design  data  is  a  CAD  model,  the  lofting 
process  also  requires  the  elimination  of 
infonnation.  If  the  source  of  the  product 
data  is  a  3D  CAD  model,  then  the  first 
step  of  the  lofting  process  consists  of  the 
extraction  of  one  part’s  worth  of  data, 
one  at  a  time,  for  each  part  in  the  model. 
At  this  time,  the  defined  transformation 
takes  the  part  from  its  CAD  coordinate 
system,  to  a  specified  location  in  the 
manufacturing  coordinate  system.  The 
solid  model  must  also  be  converted  to  a 
two-dimensional  outline  with  attributes 
such  as  thickness. 

The  next  step  of  the  lofting  process  is  the 
addition  of  manufacturing  features.  The 
design  model  captures  a  nominal  final 
condition  of  the  plate.  The  design  model 
should  be  kept  separate  from  the 
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manufacturing  features  because  the  same 
part  could  be  manufactured  differently 
depending  on  shipyard,  end  use  or  other 
manufacturing  specific  requirements.  In 
fact,  for  steel  plates  in  shipbuilding 
applications,  the  relationship  of  the 
design  model  to  the  lofted 
(manufacturing)  model  is  quite  different 
from  that  found  in  other  disciplines  and 
other  industries.  For  example,  for  parts 
that  are  produced  by  milling,  the  design 
model  typically  describes  the  final 
manufactured  shape  of  the  part. 
Manufacturing  features  define  the 
operations  that  must  be  applied  to  a 
stock  part  in  order  to  produce  that  shape. 
Operations  always  consist  of  the 
removal  of  material.  The  situation  is 
different  for  lofted  plates;  the  design 
product  model  only  partially  represents 
the  shape  of  the  finished  product.  The 
design  model  typically  describes  square 
edges  that  abut  to  other  parts.  However, 
these  edges  are  sometimes  beveled 
during  manufacture  and  then  filled  with 
weld  during  assembly  or  installation.  As 
a  result,  the  manufacturing  product 
model  may  have  to  alter  the  shape  of  the 
edge  of  the  plate.  The  lofted  model 
represents  an  in-process  version  of  the 
shape  of  the  plate.  This  means  that  the 
CAM  system  must  be  capable  of  editing 
the  shape  of  the  design  product  model;  it 
needs  a  fairly  complete  CAD  capability. 

Additional  manufacturing  features  also 
alter  the  original  design  model.  For 
example,  some  plates  require  added 
stock  for  fit-up.  The  lofted  model  must 
be  able  to  represent  the  geometry  of  the 
new  shape.  On  the  other  hand,  some 
plates  need  to  adjust  to  compensate  for 
weld  shrinkage.  Part  of  the  lofting 
process  entails  the  capturing  of  these 
changes  to  design  model.  In  addition, 
manufacturing  features  need  to  be  added 


to  define  the  welding  requirements  for 
each  edge.  This  may  include  the 
selection  of  appropriate  weld  type  as 
well  as  the  correct  bevel.  These 
decisions  may  be  based  on 
manufacturing  requirements  that  vary 
from  shipyard  to  shipyard  or  even  for 
different  end  uses  of  the  same  part 
design. 

The  final  step  of  the  lofting  process  is 
the  transfer  of  the  lofted  model  to  the 
cutting  NC  controller.  In  some  cases  the 
lofted  model  may  be  transformed 
directly  to  NC  code,  but  the  more 
common  case  is  that  the  lofted  model  is 
imported  into  a  nesting  system.  Today 
that  means  that  the  data  is  conveyed 
using  some  surfaced-based  file  fonnat. 
Surfaces  are  needed  to  convey 
information  about  bevels.  The  most 
common  formats  are  IGES,  DXF  and 
APT.  However,  all  these  formats  are 
somewhat  out  of  date,  and  none 
completely  represents  the  information 
that  needs  to  be  conveyed  for  full 
automation).  These  formats  are 
predominantly  geometry  based,  driven 
by  the  capabilities  of  CAD  systems. 
What  is  needed  is  feature-based 
representation  that  is  more  concise  and 
that  conveys  a  more  intelligent 
representation  that  can  be  used  as  input 
to  the  nesting  system. 

State  of  the  art 

There  are  three  different  strategies  that 
have  been  used  to  provide  lofting 
systems  technologies  support  in  U.S. 
shipbuilding.  Some  CAD  vendors, 
particularly  those  that  offer  shipbuilding 
specific  packages,  provide  lofting 
capabilities  as  modules  of  their  CAD 
offerings.  A  variant  of  this  approach 
entails  the  integration  of  lofting  and 
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nesting  capabilities  in  the  same  CAD 
package.  The  third  approach,  followed 
by  a  number  of  shipyards,  is  to  build 
custom  applications  that  link  their  CAD 
systems  and  their  steel  processing 
systems.  These  applications  also  include 
lofting  capabilities. 

Integrated  CAD-Lofting-Nesting 

KCS  offers  the  TRIBON  Ml  Hull 
package,  which  integrates  CAD,  lofting 
and  nesting  capabilities.  The  TRIBON 
system  is  tightly  integrated  and  uses  an 
approach  that  is  feature-based.  The  basic 
feature  supported  by  TRIBON  Ml  Hull 
is  the  panel.  A  panel  is  a  functional 
structure,  and  it  is  used  to  represent 
structural  items  ranging  in  size  from 
angle  brackets  to  decks  and  bulkheads  to 
webs  and  girders.  The  panel  is  the  data 
structure  that  captures  the  associations 
between  the  various  structural  parts  that 
comprise  it.  These  associations  are  a  pre¬ 
requisite  for  automating  the  selection  of 
manufacturing  features  during  the  lofting 
process.  It  is  not  enough  to  know  the 
characteristics  of  a  structural  part  in 
order  to  loft  it;  it  is  also  necessary  to 
know  the  characteristics  of  its  connected 
parts.  In  this  context,  TRIBON  also 
provides  a  capability  for  rules.  In  many 
instances  actual  geometry  at  structural 
joints  can  be  computed  based  on  the 
conditions  described  by  the  panel  and 
the  base  of  customizable  shipbuilding 
rules  and  standards. 

Within  its  CAD  modules  TRIBON 
supports  the  definition  of  formed  parts, 
and  flat  plate  parts.  Curved  parts  are 
developed  interactively,  often  based  on 
surfaces  defined  by  other  panels.  A 
curved  panel  capability  can  be  used  to 
build  complete  shell  panels,  including 
shell  plates  and  detailed  descriptions  of 


longitudinals  and/or  transversals.  The 
Planar  hull  module  is  used  to  model 
panels  that  represent  flat  plates, 
including  plates,  stiffeners,  brackets,  and 
flanges.  TRIBON  manages  the  structural 
joints  such  that  parts  are  connected  to 
edges  of  adjacent  parts,  allowing  a 
portion  of  the  lofting  process  (generation 
of  edge  geometries)  to  be  automated. 
Finally,  because  all  this  work  takes  place 
within  the  CAD  environment  itself,  other 
geometric  capabilities  for  lofting  are 
well  supported.  For  example,  a  facility  is 
available  to  compensate  for  weld 
shrinkage. 

TRIBON  also  includes  its  own  nesting 
sub-system,  which  is  driven  directly 
from  the  TRIBON  lofted  model.  This 
system  is  described  below. 

Integrated  CAD-Lofting 

Intergraph’s  I/LOFT  module  also 
integrates  lofting  and  CAD  capabilities 
directly.  However,  the  Intergraph 
solution  does  not  include  its  own  nesting 
capability.  As  with  TRIBON,  the 
Intergraph  package  supports  the 
extraction  of  individual  parts  from  the 
CAD  model  for  lofting.  This  is  an 
interactive  process  in  Intergraph  and  is 
integrated  with  a  production 
planning/assembly  capability,  in  which 
individual  structural  parts  can  be 
grouped  into  assemblies,  which  feed 
larger  assemblies  as  well  as  blocks  or 
units.  The  assembly  capability  also 
provides  a  capability  by  which  lofted 
parts  can  be  compared  to  determine 
which  parts  are  identical.  The  I/LOFT 
package  also  provides  an  “unwrap” 
function  for  formed  parts.  The 
unwrapped  plate  model  contains  the 
characteristic  lines,  including  structural 
markings  indicating  material  direction; 
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roll  lines  for  curved,  shell  plates;  datum 
lines  for  accuracy  control;  and 
waterlines. 

The  I/LOFT  module  also  supports  the 
addition  of  manufacturing  geometry. 
Bevels,  extra  stock  and  compensation  for 
shrinkage  can  be  modeled  geometrically 
in  the  CAD  model.  In  the  Intergraph 
system  the  adjusted  model  feeds  the 
lofting,  nesting  and  manufacturing 
processes. 

Custom  Lofting  capabilities 

The  highly  integrated  single-system 
approaches  are,  in  general,  not  used  in 
the  bigger  shipyards.  Single-system 
approaches  sometimes  lack  some 
functionality  that  is  required  for  naval 
shipbuilding.  For  example,  submarine 
and  carrier  programs  rely  heavily  on  hull 
effectiveness  for  the  configuration 
management  of  design  to  manufacturing 
data.  Moreover,  these  shipyards  tend  to 
favor  best-of-breed  applications  among 
the  sub-systems  that  support  the  overall 
design-lofting-nesting-cutting  process. 
One  factor  in  the  deployment  of  first- 
generation  systems  is  that  the  shipyards 
differ  with  respect  to  manufacturing 
capabilities  and  constraints  and  consider 
some  of  these  differences  as  key 
discriminators.  Accordingly,  the 
manufacturing  systems  at  such  shipyards 
were  best  served  by  custom-built 
applications.  For  example,  Avondale 
shipyard  uses  the  SPADES  system  for 
steel  processing.  The  current  version 
imports  infonnation  from  Intergraph 
ISDP.  Electric  Boat  uses  custom-built 
software  that  accesses  product  design 
data  from  CATIA.  In  both  systems  the 
information  that  captures  the  relevant 
design  and  manufacturing  features  is 


often  managed  outside  the  CAD  model 
itself. 

Opportunities 

This  section  describes  some  areas  in 
which  new  systems  technologies 
capabilities  could  improve  the  efficiency 
of  the  lofting  and  nesting  processes: 

Feature-based  design  product  models 

Today’s  CAD  systems  are 
predominantly  geometry-based  and  do 
not  adequately  capture  design  or 
manufacturing  features.  The  result  is  that 
it  is  very  easy  for  operators  (even 
experienced  ones)  to  build  geometric 
models  that  look  complete  but  which  fail 
to  capture  information  required  for  CAM 
processes  such  as  lofting.  Features  are  a 
more  concise  and  more  meaningful 
means  for  representing  the  product 
model.  Geometry  can  be  readily 
generated  from  features,  but  features 
cannot  be  readily  generated  from 
geometry.  Current  shipbuilding  IPDEs 
make  heavy  use  of  geometry-oriented 
CAD  models.  Major  cultural  and 
technological  changes  need  to  be  made 
before  a  feature-based  is  widely 
deployed  across  the  U.S.  shipbuilding 
industry.  This  is  especially  evident  in  the 
processes  connected  with  steel 
processing.  It  is  often  difficult  (or 
impracticable)  to  derive  design  intent 
from  geometry  alone.  In  fact,  even  when 
CAD  geometry  can  be  imported  into  the 
CAM  system,  it  cannot  be  used  until  a 
large  volume  of  irrelevant  geometric 
detail  is  filtered  out  from  the  model. 
Since  there  is  nothing  in  the  CAD  to 
indicate  the  purpose  or  intent  of  most  of 
the  geometry,  the  process  of  filtering 
cannot  be  automated  and  is  usually 
prohibitive  for  an  operator.  As  noted 
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above,  the  custom  CAM  systems 
deployed  at  some  shipyards  manage  the 
necessary  design  and  manufacturing 
features  outside  the  CAD  environment 
per  se.  These  services  need  to  be  made 
available  in  conjunction  with  CAD 
system  but  in  a  way  that  is  decoupled 
from  the  CAD  geometry.  CAD  tools 
need  to  provide  the  ability  for  the  design 
to  designate  which  infonnation  is 
pertinent  to  downstream  applications 
such  as  CAM. 

Product  data  management  for  CAM 
(lofting)  data 

Today’s  shipyard  IPDEs  have  all 
adopted  some  degree  of  Product  Data 
Management  (PDM)  capability;  the  kind 
and  degree  varies  widely  from  shipyard 
to  shipyard.  However,  there  is  an 
opportunity  for  improved  configuration 
management  and  increased  productivity 
by  more  effective  management  of 
shipbuilding  CAM  infonnation.  It  is  a 
very  costly  mistake  if  steel  is  cut  to  an 
obsolete  product  model.  CAM  product 
models  should  be  managed  independent 
of  their  supporting  CAD  models.  The 
introduction  of  CAM  information 
directly  into  the  CAD  model  makes  the 
design  model  very  resistant  to  change 
and  inhibits  design  improvements  and 
technological  innovations.  Improved 
facilities  for  the  association  of  CAM 
product  data  and  CAD  product  data  are 
needed.  It  should  be  possible  to  associate 
CAM  work  products  to  each  other  as 
well  as  to  relevant  CAD  model  at  the 
piece  part  level.  For  example,  if  the 
design  of  piece  part  is  changed,  the 
system  should  be  able  to  ensure  that  no 
nest  file  that  contains  the  part  will  be 
cut.  By  the  same  token,  it  should  be 
possible  to  perfonn  a  check  on  a  nest  file 
that  the  design  for  each  piece  part  in  the 


file  is  still  valid.  The  problem  is 
especially  important  to  yards  that  rely  on 
hull  effectiveness  to  manage  design 
work  products. 

Automation  of  the  lofting  process 

As  stated  in  the  NSRP  Benchmarking 
Report  (NSRP[2001j)  the  automation  of 
the  lofting  process  is  a  key  area  for 
potential  process  improvements.  In  most 
U.S.  shipyards  the  lofting  process  has 
been  computerized  and  has  links  to  the 
CAD  product  models,  and,  in  fact,  some 
degree  of  automation  exists.  However, 
there  are  still  many  manual  steps 
involved.  For  example,  an  operator 
typically  determines  and  enters  the 
manufacturing  features  that  consist  of 
bevel  selection,  weld  shrinkage 
adjustments,  added  stock,  etc.  These 
steps  could  be  further  automated,  but 
there  are  some  pre-requisites  to  this  level 
of  automation.  These  decisions  are  based 
on  manufacturing  capabilities  and 
associated  rules  that  vary  from  shipyard 
to  shipyard.  There  needs  to  be  a  way  to 
represent  and  manage  these 
manufacturing  requirements  and  rules. 
This  includes  the  rules  for  associating 
welding  types  with  manufacturing 
requirements.  The  system  that  supports 
these  rules  must  be  flexible  enough  so 
that  the  rules  can  be  tailored  per 
shipyard. 

Improved  interface  to  accuracy  control 
systems 

The  enhanced  PDM  system  described 
above  is  a  pre-requisite  for  improved 
interfaces  to  accuracy  control  systems. 
The  PDM  system  should  be  designed  to 
manage  the  association  of  lofted  and 
nested  items  with  their  respective 
inspection  requirements  and  inspection 
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results.  In  addition  the  PDM  capabilities 
lofting  (and  nesting)  systems  need  to 
begin  utilizing  a  feature-based 
representation  that  is  suitable  for 
generating  inspection  features.  Better 
tools  are  needed  to  transform 
manufacturing  features,  specific  to  the 
constraints  of  the  lofting  process  and  to 
geometric  representations. 

Need  to  move  away  from  obsolete  data 
formats 

The  lofting  and  nesting  processes, 
especially  for  loosely  coupled  systems, 
are  very  dependent  on  the  sharing  of 
complex  CAM  product  data. 
Unfortunately  most  of  the  exchanges  are 
still  done  using  obsolete  formats  such  as 
IGES  or  APT.  These  formats  are 
limiting  because  on  the  one  hand,  they 
are  geometry  oriented,  and,  on  the  other 
hand,  are  based  on  technologies  that  are 
no  longer  widely  supported.  A  feature- 
based  neutral  format  needs  to  be 
developed  and  widely  implemented 
among  lofting  software  systems.  This 
format  should  be  standards-based  using 
the  STEP  and  STEP-NC  framework.  The 
data  format  should  be  based  on  XML  so 
that  these  systems  can  take  advantage  of 
the  wide  range  of  software  tools  now 
available  for  managing  XML  data. 

Better  support  for  inter-company  data 
sharing 

Today  it  is  difficult  (if  not  impossible)  to 
use  CAD-based  design  data  from  one 
shipyard  to  drive  the  lofting  and  nesting 
processes  at  another  shipyard.  The 
typical  scenario  is  that  an  opportunity  for 
work  sharing  arises  but  there  is  not 
sufficient  time  to  build  a  customized 
solution  for  such  data  sharing.  The  result 
is  that  the  opportunity  for  work  sharing 


is  lost,  or  the  data  is  re-entered 
manually.  This  situation  applies  not  only 
between  independent  shipyards  but  also 
between  sister  shipyards  within  one 
corporation.  Modern,  neutral  form  data 
sharing  capabilities  will  improve  this 
situation.  The  NSRP  Integrated  Steel 
Processing  Environment  (ISPE)  is 
addressing  many  aspects  of  this  issue.  A 
complete  solution  needs  to  support  the 
ability  to  import  or  export  at  each  step  of 
the  process  starting  with  the  nominal 
design  model  but  also  including  the 
CAM  features  as  well  as  the  post- 
processed  NC  code.  Different  entry 
points  support  different  alternatives  and 
capabilities.  For  instance,  with  the  CAD 
and  design  features,  a  shipyard  can  build 
its  own  manufacturing  plan;  this  would 
be  impossible  if  only  NC  files  were 
exchanged. 

Improved  interoperability  with  ERP  data 

Lofting  and  nesting  operations  are 
typically  controlled  and  scheduled 
within  the  shipyards  ERP/MRP  system. 
The  sharing  of  structural  processing 
work  between  shipyards  requires  more 
than  just  the  design  and  manufacturing 
models;  it  is  also  needs  to  be 
incorporated  into  the  shipyards 
management  and  control  systems.  This 
kind  of  work  cannot  be  shared  with  a 
coordinated  schedule.  What  is  needed 
are  better  ways  to  share  management  and 
control  data,  and  facilities  to  link  the 
lofting  and  nesting  operations  with  this 
shared  information. 

Decoupling  of  CAD  and  CAM  data 

Projects  such  as  the  NSRP  ISPE  project 
have  recognized  the  need  to  de-couple 
CAD  and  CAM  data.  There  is  pressure 
from  the  specialized  CAD  platfonn  to 
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merge  this  data  within  a  particular  CAD 
environment.  However,  when  CAM  data 
is  too  tightly  intenningled  with  CAD 
data  it  becomes  very  difficult  to  re-use 
the  design  data.  For  example,  it  is  very 
difficult  to  accomplish  re-design  work 
on  such  data,  and  it  is  very  difficult  to 
share  such  data  with  other  shipyards. 
The  decoupling  of  CAD  and  CAM  data 
is  also  a  pre-requisite  to  the 
modularization  of  the  steps  in  the 
lofting/nesting  process.  Best  of  breed 
tools  for  each  step  can  only  be  deployed 
if  there  is  a  clear  layering  of  the 
information  required  for  each  module. 

Nesting 

The  nesting  process  consists  of  the 
arranging  of  flat  parts  or  profile  parts 
with  respect  to  raw  stock  in  order  to 
maximize  some  user  objective.  Often, 
the  objective  is  to  minimize  waste,  but  it 
could  be  some  other  objective  as  well. 
The  nesting  process  is  illustrated  in 
Figure  2: 


Figure  2:  Nesting  Process 

The  nesting  process  has  three  inputs:  the 
manufacturing  requirements,  which 
include  the  definition  of  the  objective  of 
the  nesting;  the  schedule,  which  defines 


the  needs  dates  for  a  set  of  parts;  the 
geometry  and  manufacturing  features  for 
a  set  of  lofted  parts.  The  nesting  process 
arranges  the  lofted  parts  with  respect  to 
the  raw  stock.  The  output  of  the  process 
is  the  CNC  code,  which  will  drive  the 
cutting  machines  to  produce  the  parts. 
As  described  above,  there  are  two 
prominent  systems  approaches  to 
nesting:  nesting  software  provided  by 
and  directly  bound  to  a  CAD/CAM 
system  (e.g.  TRIBON  and  Foran)  and 
nesting  software  that  is  decoupled  from 
the  CAD/CAM  system  (e.g.  Sigmatek 
and  OptiShip).  The  integrated  approach 
has  the  advantage  of  close  integration 
but  it  limits  interoperability  with  other 
systems.  The  decoupled  approach 
assumes  that  the  lofting  process  has  been 
completed.  It  typically  accepts  geometry 
in  the  form  of  IGES,  DFX  or  APT  file. 
For  the  most  part  feature  information  is 
lost  in  the  data  transfer  process.  This 
limits  the  potential  for  the  application  of 
rules  in  the  nesting  algorithms. 

State  of  the  art 

Besides  the  strategic  placement  of 
individual  pieces,  the  main  task  of  the 
nesting  process  is  the  generation  of  tool 
paths  from  the  CAD/CAM  product 
model.  Because  the  problem  is  quite 
constrained,  it  has  been  possible  to  fully 
automate  nearly  all  aspects  of  the 
process,  assuming  that  all  manufacturing 
requirements  are  available  to  the  system. 
The  generation  of  tool  paths  entails 
adjustments  for  kerf  (offsetting  the  tool 
path  to  compensate  for  material  lost 
during  cutting),  for  material  expansion 
and  for  weld  shrinkage.  The  tool  path 
generation  must  also  guarantee  that  no 
idle  pass  crosses  over  a  previously  cut 
part.  Nesting  software  should  also 
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support  the  generation  of  marking  paths 
as  well  as  cutting  paths. 

One  technical  issue  is  the  relationship 
between  nesting  software  and  the 
machine  controllers  for  cutting.  Today 
the  interface  between  the  nesting 
software  is  still  based  on  M&G  or  ESSI 
formats.  This  is  a  machine-level 
interface  and  as  such  there  are  always 
minor  differences  between  controllers. 
The  nested  model  is  always  post- 
processed  into  a  fonnat  suitable  for  a 
particular  machine.  This  means  that 
optimizations  of  tool  path  generation 
cannot  be  done  at  the  controller  itself, 
but  must  be  completed  beforehand  and 
in  a  general  fashion.  Nevertheless,  this 
approach  has  been  widely  adopted 
within  the  shipbuilding  industry.  A  very 
small  set  of  nesting  software  vendors  is 
able  to  support  a  wide  array  of  cutting 
equipment.  In  addition,  the  nesting 
process  is  somewhat  different  from  other 
tool  path  generation  processes  because, 
on  the  one  hand,  it  entails  the 
organization  of  multiple  piece  parts 
resulting  in  added  complexity;  but,  on 
the  other  hand,  the  limited  feature  set 
and  geometric  constraints  make  it  a 
simpler  problem.  The  upshot  is  that  the 
current  positioning  of  nesting  software 
systems  between  the  lofting  phase  and 
the  cutting  machine  should  not  be 
changed. 

Integrated  Lofting/Nesting  systems 

Integrated  lofting/nesting  systems  are 
typically  used  by  smaller  yards.  These 
systems  are  generally  functionally 
adequate,  but  they  may  not  scale  up  to 
support  the  needs  of  defense 
shipbuilding.  On  the  other  hand,  the 
smaller,  integrated  systems  are  richer  in 
their  use  of  feature -based  design.  This 


offers  a  better  opportunity  for 
optimizations  in  the  nesting  process. 

KCS’s  TRIBON  Ml  Hull  is  one  instance 
of  an  integrated  lofting/nesting  system.  It 
is  based  on  the  feature-based  product 
model  that  is  created  in  the  TRIBON 
Hull  design  and  lofting  system.  The 
product  model  includes  assembly  and 
weld  information;  rules-based  generation 
of  manufacturing  features;  and 
definitions  of  structural  joints.  More 
product  details  may  be  found  at  the 
Tribon  web  site  http://www.tribon.com. 

Sener’s  Foran  system  also  provides 
integrated  lofting/nesting,  which 
supports  the  nesting  of  both  plates  and 
profiles.  Tool  path  generation  is  semi- 
automated.  Parts  for  nesting  are  selected 
from  the  database  those  parts  that  match 
the  thickness  and  material  of  the  chosen 
raw  stock.  The  nesting  is  accomplished 
by  an  operator’s  using  a  combination  of 
rotation,  translation  and  mirroring 
commands.  The  operator  also  has  the 
ability  to  group  parts  and  to  duplicate 
parts  or  groups.  The  final  tool  path  can 
be  generated  by  defining  the  piercing 
points  and  the  kerf  position  to  be  used 
for  all  parts.  It  may  also  be  generated 
sequentially  or  contour  by  contour. 
More  product  details  may  be  found  at 
www .  foransy  stem,  com . 

Decoupled  Nesting  Systems 

U.S.  defense  shipyards  use  decoupled 
nesting  systems.  These  systems  are 
provided  by  vendors  that  specialize  in 
the  nesting  process.  The  input  to  these 
programs  is  a  neutral  file  representation 
of  the  geometry  of  each  lofted  part  - 
usually  in  IGES,  DFX  or  APT  fonnat. 
The  major  decoupled  nesting  systems  in 
use  at  U.S.  shipyards  are  Optimation’s 
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Optiship  and  Sigmatek’s  SigmaNest. 
More  product  details  may  be  found  at 
http://www.optimation.co.nz/  and 
http://www.sigmanest.com/. 

Opportunities 

Improved  integration  with  ERP 

The  nesting  process  is  interdependent 
with  the  shipyard  resource  planning 
processes,  including  manufacturing 
schedules  and  material  ordering.  Current 
systems  offer  some  degree  of  integration 
with  ERP  capabilities,  but  there  is  a  need 
for  improved  interoperability  between 
these  systems.  A  standard  representation 
of  scheduling  and  other  resource 
planning  information  would  make  it 
easier  to  integrate  the  nesting  systems 
with  the  shipyard  schedules.  Nesting  is 
typically  performed  nowadays  as  a  batch 
process  well  in  advance  of  need  dates.  A 
better  integration  with  ERP  systems 
would  be  an  enabler  for  just-in-time 
nesting  capabilities. 

Accuracy  control 

Nesting  systems  do  not  typically 
maintain  the  identity  of  parts  in  the  post- 
processed  machine  code.  Nesting 
systems  should  support  the  addition  of 
more  meaningful  information  onto  the 
cut  plates  themselves  in  order  to 
expedite  and  improve  the  process  of 
collecting  meaningful  accuracy  control 
information 

b.)  Pipe 
Background 

This  section  describes  CAD/CAM/CIM 
systems  for  the  production  of  piping 
systems,  with  an  emphasis  on 
CAM/CIM.  CIM  for  piping  systems  has 


a  number  of  similarities  with  CIM  for 
ship  structures.  If  structural, 
manufacturing  process  can  be  thought  of 
as  a  2-Vi  D  problem,  then  the 
manufacturing  process  for  piping  can  be 
thought  of  as  a  I-V2  D  problem.  The 
piping  system  is  almost  completely 
specified  by  the  composite  curve  that 
represents  the  piping  path.  The 
remainder  of  the  product  model  can  be 
specified  by  means  of  a  relatively  small 
number  of  feature -based  attributes.  As 
with  structural  CAD,  however,  the  solid 
modeling  orientation  of  the  today’s  CAD 
platforms  demands  a  full  solid 
representation  of  the  piping  system.  In 
some  cases  the  solid  model  is  in  addition 
to  the  piping  product  model,  but  in  some 
systems  the  solid  model  is  presented 
instead  of  the  piping  product  model. 
Those  systems  capture  a  solid  model  that 
looks  like  a  piping  system,  especially  in 
the  context  in  which  the  piping  system 
resides,  but  they  do  not  represent  a  true 
piping  product  model. 

The  shipbuilding  industry  has  focused 
most  efforts  in  the  area  of  CAD  support 
for  piping  systems.  Even  the  major  CAD 
vendors  now  support  product  modeling 
of  piping  systems.  The  piping  product 
model  is  fairly  well  understood  and,  in 
fact,  well  supported  in  other  industries  as 
well.  The  STEP  standard  for  piping 
systems  originated  in  the  process  plant 
industry  and  was  later  adopted  (and 
enhanced)  by  the  shipbuilding  industry. 
In  fact,  a  standards-based  piping  product 
model  has  been  used  for  the  basis  of 
production  data  exchange  in  major 
submarine  programs,  and  the  exchanges 
have  encompassed  both  custom 
developed  piping  CAD  packages  as  well 
as  COTS  CAD  platforms.  Consequently, 
the  piping  discipline  is  ahead  of  some  of 
the  others  in  its  use  of  a  feature-based 
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design  model  as  the  input  to 
manufacturing  and  planning  systems. 

Manufacturing  infonnation  for  piping 
systems,  as  with  structures,  includes 
both  CAM  and  NC  aspects.  The  goal  is 
to  develop  the  machine  instructions  to 
automate  the  manufacturing  process. 
There  are  two  operations  that  need  to  be 
supported:  nesting  and  bending.  Nesting 
consists  of  determining  the  appropriate 
lengths  to  be  cut  and,  possibly,  marked. 
The  bending  operation  requires  that 
instructions  be  generated  to  drive  a  pipe¬ 
bending  machine.  Today  these 
operations  can  be  nearly  fully  automated 
based  on  the  piping  product  model. 

What  is  missing  from  the  product  model 
is  the  CAM  information.  Most  important 
is  the  definition  of  the  parameters  of  the 
actual  machines  that  will  be  used  for  the 
cutting  and  bending.  Each  machine  has 
its  own  constraints  and  limitations.  For 
example,  in  the  pipe  bending  process,  if 
the  pipe  is  too  long  or  bent  in  a  bad 
configuration,  the  pipe  may  collide  with 
the  floor,  ceiling  or  with  the  machine 
itself.  The  necessary  CAM  data  then 
includes  not  only  a  model  of  the 
machines  themselves  but  also  an 
indication  of  which  machine  will  be  used 
for  each  pipe  detail. 

Other  parameters  to  be  considered 
include  springback,  weld  shrinkage  and 
wall  thinning.  Because  the  product 
model  doesn’t  always  consider  the  CAM 
information,  a  manufacturing  model  is 
often  created  where  the  parts  are 
modified  to  account  for  these  added 
parameters.  The  part  is  modified  in  the 
manufacturing  model  where:  it  might  be 
expanded  to  account  for  springback,  it 
might  be  cut  larger  to  account  for  weld 
shrinkage  or  maybe  a  different  machine 


is  chosen  to  avoid  unwanted  wall 
thinning.  With  this  type  of  infonnation, 
it  is  possible  to  construct  a 
manufacturing  plan  with  reasonable 
assurance  of  its  productivity. 

State  of  the  art 

Today  CAM  information  for  piping 
systems  is  captured  and  managed  in 
custom  applications  at  U.S.  shipyards. 
Defense  yards  already  manage,  more  or 
less,  the  same  of  amount  of  information 
within  the  piping  CAD  product  model, 
and,  in  fact,  Navy  programs  have 
successfully  exchanged  such  models  in 
support  of  co-production  scenarios.  U.S. 
shipyards  have  also  developed  the 
capability  (in  these  custom  applications) 
to  perform  design  and  manufacturing 
rules  checking.  After  the  CAM  data  is 
captured  and  associated  with  the  CAD 
product  model,  it  is  possible  to  check  for 
hits  or  other  inconsistencies  in  the 
manufacturing  plan. 

Opportunities 

Standard  CAD/CAM  exchange  format 

The  standard  for  the  exchange  of  piping 
CAD  data  is  very  well  defined  and 
beginning  to  be  implemented;  however, 
there  is  still  a  need  to  standardize  the 
CAM  information,  including  tool 
definitions,  for  piping.  Currently,  piping 
exchanges  in  co-production  scenario 
may  be  shipyard  specific.  The  necessary 
manufacturing  features  for  piping 
systems  should  be  standardized  within 
the  STEP-NC  standards.  There  is  a  Navy 
Phase  I  SBIR  that  is  currently  addressing 
this  issue. 

CAD  and  CAM  rules  checking 
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Today  CAD  and  CAM  rules  are  checked 
for  the  most  part  within  custom-built 
applications  at  each  shipyard.  Once  the 
standard  features  for  both  CAD  and 
CAM  for  piping  have  been  agreed  to,  it 
becomes  possible  to  have  more  open 
tools  that  perfonn  rules  checking.  The 
first  step  is  to  move  the  rules  out  of 
procedural  programs;  current 
applications  are  still  largely  FORTRAN- 
based.  A  declarative  rules  engine  will 
make  it  easier  for  shipyards  to  deploy  an 
off-the-shelf  CAD/CAM  validator, 
which  can  be  populated  with  its  own 
rules. 

Automated  planning 

A  time-consuming  step  in  the 
CAD/CAM  process  for  piping  is  the 
definition  of  pipe  details.  A  pipe  detail 
represents  a  unit  of  manufacture.  It  is  a 
unit  that  consists  of  one  bent  pipe 
(possibly  with  fittings  at  one  or  both 
ends)  or  a  combination  of  straight  pipes 
and  fittings  that  when  assembled  lie  in 
one  plane.  There  are  many  ways  to 
divide  a  piping  system  into  pipe  details 
(and  later  into  assemblies),  some  more 
costly  than  others.  There  is  a  need  for  a 
system  that  can  automate  this  planning 
process.  The  system  would  have  to  take 
into  account  the  piping  product  model, 
the  manufacturing  constraints  and 
requirements,  the  associated  CAM  data, 
and  the  costs  associated  with  each 
manufacturing  option.  A  current  SBIR 
project  is  prototyping  such  a  system. 

PDM  capabilities  for  configuration 
management 

There  is  a  pressing  need  for 
configuration  management  capabilities 
in  the  piping  manufacturing  process.  A 
piping  system  is  typically  decomposed 


into  assemblies,  pipe  details,  and 
components.  Each  lower  level  entity 
must  be  configuration-managed  with 
respect  to  its  higher  level  collectors. 
Entities  may  be  versioned  at  each  level. 
Currently  configuration  management  is 
performed  either  within  the  shipyard’s 
custom-built  application  or  in  an  ad-hoc 
manner.  PDM  capabilities  are  expanding 
to  begin  to  manage  data  at  a  piece  part 
level;  these  capabilities  should  be 
expanded  so  that  they  can  be  used  to 
manage  piping  manufacturing 
configurations.  The  problem  is  the  large 
number  of  items  that  comprise  shipboard 
piping  systems.  The  configuration 
management  system  must  be  easy 
enough  to  use  so  that  users  are  not 
tempted  to  short  cut  the  system. 

Interference  checking 

There  is  a  need  for  specialized 
interference  checking  for  piping 
manufacturing.  The  pipe  bending 
process  is  sensitive  to  hits  as  the  pipe  is 
processed.  Conventional  CAD  systems 
are  able  to  perform  static  interference 
checking  on  solid  geometric  models.  The 
piping  problem  is  different  from  this.  On 
the  one  hand  it  is  a  dynamic  problem 
since  hits  occurs  at  the  pipe  moves  about 
the  machine.  On  the  other  hand,  it  is  a 
simpler  problem  from  a  computational 
geometry  perspective.  The  interference 
problem  can  be  solved  as  an  intersection 
of  curves  (the  pipe  path)  and  surfaces 
(adjoining  ceiling,  walls,  machine,  etc.) 

c.)  Sheet  Metal 
Background 

This  section  describes  CAD/CAM/CIM 
systems  for  the  production  of  sheet  metal 
work  products,  with  an  emphasis  on 
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CAM/CIM.  CIM  for  sheet  metal  has  a 
number  of  similarities  with  CIM  for  flat 
plate  processing.  Like  the  flat  plate 
structural  manufacturing  process, 
manufacturing  sheet  metal  can  be 
thought  of  as  a  2Vi  D  problem.  In  some 
ways  the  sheet  metal  task  is  simpler. 
There  are  no  bevel  configurations  to 
contend  with,  so  in  this  respect  the 
features  associated  with  the  edges  of  the 
sheet  metal  of  simpler.  There  are  fewer 
CAM  requirements.  On  the  other  hand, 
because  the  material  is  cheaper  and  more 
manageable,  the  lofting  process  becomes 
more  involved.  While  it  makes  sense  to 
cut  and  manage  steel  plate  one  piece  at 
time,  typically  an  entire  sheet  metal 
assembly  is  cut  and  managed  as  a  unit. 
Finally,  the  automation  of  the  sheet 
metal  manufacturing  process  can  also 
includes  a  bending  operation,  which  can 
potentially  be  generated  from  the  CAM 
model. 

The  sheet  metal  process  begins  with  a 
CAD  model  of  the  finished  assembly. 
The  first  step  of  the  CAM  process  is 
lofting.  As  with  plate  processing,  the 
lofting  stage  consists  of  the  separation  of 
the  assembly  into  each  individual  part, 
which  can  be  cut  from  flat  stock. 
Generally,  there  is  more  involved  in  this 
step  than  in  the  corresponding  step  for 
structures.  The  typical  structural  CAD 
model  keeps  track  of  the  individual 
component  pieces.  This  is  not  the  case 
with  sheet  metal  models.  There  are  a 
number  of  ways  that  a  flat  sheet  can  be 
cut  and  bent  to  form  a  box;  some  of 
these  ways  are  preferable  to  others  given 
the  constraints  of  the  sheet  metal  shop. 
At  the  lofting  step,  the  productivity  of 
the  assembly  must  be  addressed.  (As  the 
design/build  process  is  more  completely 
utilized,  these  decisions  may  be  pushed 
back  to  the  design  stage;  however,  when 


multiple  shops  are  to  be  used,  it  is 
preferable  to  keep  the  CAD  and  CAM 
features  separate  from  each  other.)  The 
lofting  step  may  include  an  unrolling 
step  for  pieces  with  curved  surfaces.  The 
next  step  is  nesting,  which  is  a 
straightforward  flat  pattern  operation. 
After  nesting,  NC  code  may  be 
generated  to  drive  the  cutting  and 
bending  machines. 

State  of  the  art 

In  general,  shipbuilding  CAD/CAM 
requirements  are  more  demanding  than 
the  requirements  of  other  industries,  and 
this  situation  is  especially  severe  for 
sheet  metal.  The  requirements  for  sheet 
metal  CAD/CAM  processing  are 
complex  and  yet  the  potential  payback 
for  sheet  metal  is  not  perceived  to  be  as 
significant  as  for  steel  or  piping. 
Consequently,  there  is  a  lack  of  an 
integrated  sheet  metal  CAD/CAM 
capability  in  commercial  tools.  Most  of 
the  integration  work  is  currently 
accomplished  by  means  of  custom 
developed  solutions  at  the  shipyards. 

The  CAD  requirements  for  sheet  metal 
embody  some  constraints  which,  on  the 
one  hand,  would  simplify  the 
deployment,  but  which,  on  the  other 
hand,  do  not  fit  nicely  in  the  mold  of  3D 
solid  modeling.  Within  the  shipbuilding 
industry,  there  are  two  families  of  sheet 
metal  products:  non-standard,  custom- 
design  shapes  and  standard  shapes  that 
are  re-used  frequently  (e.g.,  the  shapes 
that  comprise  ducting  systems).  The 
design  of  non-standard  shapes  is  done 
using  conventional  CAD  tools  and  may 
be  represented  as  surface  or  solid 
geometry.  Because  these  shapes  are 
made  from  flat  sheets,  all  the  geometry 
must  be  confined  to  developable 
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surfaces.  Solid  geometry  engines  do  not 
typically  recognize  such  a  constraint. 
Some  surface  modelers  support  the 
design  of  developable  surfaces,  but 
surface  modeling  is  not  in  widespread 
use  at  shipyards. 

There  is  a  better  opportunity  for  a 
feature-based,  parametric  approach  with 
the  standard  shapes.  Several  years  ago  a 
number  of  shipyards  agreed  to  a  set  of 
standard  ventilation  shapes  that  could  be 
described  parametrically.  Early  systems 
used  custom-built  code  to  create  feature- 
based  ventilation  system  models  within 
conventional  CAD  platforms.  Since  then 
the  standard  shapes  have  been 
implemented  in  Dassault’s  CATIA 
system.  This  approach  has  the  advantage 
of  a  concise  representation  from  which 
explicit  geometry  can  be  readily 
generated. 

Opportunities 

Standard  CAD/CAM  exchange  format 

The  standard  for  the  exchange  of 
ventilation  CAD  data  is  being 
standardized  as  part  of  ISO  10303-227 
version  2.  This  standard  is  incorporating 
requirements  from  the  shipbuilding 
industry.  The  approach  in  this  standard 
is  based  on  a  non-parametric  definition 
of  the  associated  geometry.  There  is 
currently  no  activity  in  the  STEP-NC 
arena  to  define  features  for  ventilation 
systems.  The  parametric  features  for 
ventilation  shapes  should  be 
standardized.  There  is  a  need  for  better 
CAD  support  of  the  ventilation  shapes 
and  a  better  integration  of  these  shapes 
with  CAM  systems.  The  CAD  platforms 
provide  the  geometry  engines  that  are 
needed  to  “unroll”  developable  surfaces. 


d.)  Robotic  Welding 
Background 

Robotic  welding  is  the  process  of  using 
an  industrial  robot  to  control  the  motion 
of  an  arc,  gas  nozzle,  laser,  or  other 
welding  tip,  and  any  associated  wire 
feed  or  sensor  equipment  during 
welding.  The  welding  path  to  be 
followed  by  the  robot  can  either  be 
taught  manually  by  an  operator, 
programmed  off-line  using  specialized 
software,  or  automatically  detennined  by 
a  combination  of  software  tools, 
geometry  models,  and  sensor  input.  The 
process  of  mechanized  or  semi- 
automated  welding,  such  as  track 
systems,  is  included  here  as  a  specialized 
form  of  robotic  welding.  The  use  of 
robotics  is  typically  associated  with 
high-rate  production  and  repetitive 
processes.  These  are  not  representative 
descriptions  of  the  shipbuilding  process, 
and  robotics  in  general  has  a  small 
presence  in  the  shipbuilding  industry. 
Robotic  welding  is  widely  used  in  the 
automotive  industry,  in  high-volume 
repetitive  operations,  although  this 
application  is  typically  spot  welding 
rather  than  continuous  bead. 
Implementations  of  robotic  welding  in 
the  shipbuilding  industry  have 
demonstrated  significant  reduction  in 
man-hours  and  improved  weld  quality. 

The  motion  of  welding  robots  used  in 
the  shipbuilding  industry  is  controlled  by 
a  variety  of  standard  methods  including 
operator  teach  pendants,  off-line 
programming  (OLP),  physical  alignment 
of  guide  tracks,  and  automated  seam 
tracking.  Manual  teach  pendants  are 
used  by  an  operator  to  train  the  robot  on 
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the  actual  work  piece.  These  can  also  be 
used  to  initially  align  and  calibrate  the 
robot  to  the  work  when  automated 
motion  programming  methods  are  used. 
With  track  based  systems  the  motion  of 
the  welding  apparatus  is  controlled  by 
one  or  more  physical  guide  rails.  These 
guides  are  attached  to  the  work  pieces 
and  used  to  align  the  welder  with  the 
joint.  The  welder  then  propels  itself 
along  the  guide  tracks  through  the  use  of 
servomotors.  The  fine  motion  of 
welding  robots  required  to  follow  a  joint 
closely  or  to  incorporate  multiple  passes 
or  bead  patterns  can  be  controlled  by 
automated  tracking  systems.  These 
tracking  systems  can  be  based  on 
physical  contact  with  touch  probes  or 
computer  vision  through  the  use  of 
optical  cameras  or  laser  sights. 

The  control  of  robotic  welding 
equipment  often  requires  the  use  of 
specialized  software.  Robot  motion  can 
be  programmed  through  the  use  of  off¬ 
line  programming  (OLP)  applications. 
OLP  tools  provide  a  virtual 
representation  of  the  work  piece  and  the 
robot,  often  making  use  of  3D  computer 
graphics,  and  allow  the  operator  to  plan 
out  and  simulate  different  motion  paths 
without  moving  the  actual  robot.  The 
benefits  of  OLP  are  that  motion  planning 
can  be  done  while  the  robot  is  busy 
doing  production  work,  many  different 
path  scenarios  can  be  tried  without 
consuming  any  steel,  and  during  the 
planning  phase  there  is  no  danger  of 
collision  for  either  the  robot  or  the 
operator. 

Another  software  tool  that  is  helpful  in 
robotic  welding  is  the  use  of  welding 
templates  or  macros.  Welding  templates 
contain  infonnation  about  a  particular 
weld  type,  for  instance  how  to  maneuver 


around  a  certain  kind  of  geometry, 
settings  to  be  used  for  joining  two 
material  types,  or  voltage/current 
parameters  for  a  given  joint  type. 
Templates  can  be  used  to  capture 
shipyard  specific  welding  rules,  or  to 
enforce  certain  welding  procedures 
where  eventual  certification  of  the  weld 
is  necessary.  Templates  and  macros  are 
created  once  and  then  reused  many 
times,  either  as-is  or  with  slight 
modification.  By  combining  a  group  of 
templates  together,  weld  planning  can  be 
accomplished  quickly  with  a  high  degree 
of  confidence. 

State  of  the  Art 

Some  form  of  robotic  welding  has  been 
incorporated  as  a  part  of  the  standard 
manufacturing  process  at  most  major 
U.S.  shipbuilders.  Robotic  welding  is 
still  a  niche  application,  and  is  not  used 
in  the  majority  of  ship  joining  activities. 
The  majority  of  automated  welding  in 
shipbuilding  is  actually  done  with  track 
systems  rather  than  multi-axis  robots. 
The  most  typical  application  of 
automated  welding  is  in  the  panel  line. 
This  represents  the  most  repetitive,  high- 
volume  activity  in  the  overall 
shipbuilding  process.  The  long,  often 
straight,  unobstructed  seams  in  plate  butt 
joints  and  stiffener  fillets  are  an  obvious 
target  for  automation.  Another 
application  area  for  automated  welding 
is  in  hull  erection  and  joining  of  major 
sections.  Here  again,  track  systems  are 
used  to  make  long  weld  passes  in 
accessible  areas.  A  number  of  shipyards 
are  beginning  to  test  the  use  of  multi¬ 
axis  robots  for  welding  of  smaller  items 
such  as  internal  tanks  and  structural 
assemblies.  This  general-purpose  use  of 
robotic  welding  is  not  yet  standard 
practice  in  the  shipbuilding  industry. 
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Opportunities 

Integration  with  the  design  process 

In  order  to  be  successfully  deployed  in 
the  shipbuilding  process  robotic  welding 
needs  to  be  integrated  as  part  of  a  larger, 
comprehensive  system  that  spans  the 
areas  of  design,  planning,  and 
manufacturing.  The  process  begins  with 
the  integration  of  welding  procedures  in 
the  product  model,  where  the  joint  types 
are  initially  defined.  Here  a  rules-based 
approach  could  be  employed  to  limit 
mating  material  types  and  sizes,  and 
specify  edge  preparation  procedures 
according  to  the  detailed  spatial 
configuration.  The  design  must  also 
take  into  account  the  particular  access 
requirements  of  the  robot  in  reaching  the 
weld  and  maneuvering  along  the  extent 
of  the  seam. 

Changes  in  construction  planning  and 
scheduling 

Robotic  welding  will  require  changes  in 
the  construction  planning  process.  The 
physical  access  requirements  of  a 
welding  robot  will  have  implications  on 
the  placement  sequence  of  piece  parts 
during  assembly  and  on  the  location  and 
type  of  fixturing  used.  A  welding  robot 
is  a  large  capital  expense,  but  also  has  a 
very  high  duty  cycle.  In  order  to  be 
utilized  most  effectively  it  needs  to  be 
constantly  working.  This  requires 
careful  scheduling  and  potential  changes 
in  the  material  flow  and  material 
handling  processes  to  provide  a  constant 
supply  of  work.  Maximizing  the  use  a 
particular  machine  is  a  different  kind  of 
constraint  than  those  normally  faced  by 
construction  planners. 


Cutting  and  material  preparation 

Robotic  welding  may  also  require 
adjustments  in  the  manufacturing 
processes  of  cutting  and  edge 
preparation.  Some  automated  welding 
equipment  requires  closer,  and  more 
consistent  fit-up  tolerances  than  those 
accommodated  by  manual  welding.  The 
seam  tracking  and  bead  weaving 
capabilities  of  the  robot  will  determine 
the  amount  of  variation  in  root  gap, 
bevel,  and  surface  finish  that  can  be 
allowed. 

Improved  software  tools 

OLP  software  is  meant  to  be  a  cost 
saving  tool  to  minimize  the  robot  down 
time  associated  with  path  planning.  In 
the  shipbuilding  environment, 
characterized  by  low  rate  production  and 
non-standardized  part  shapes,  the 
overhead  of  robot  motion  programming 
can  become  a  burden.  OLP  software  is 
typically  very  expensive  and  requires  a 
high  skill  level  to  operate.  If  every  weld 
needs  to  be  programmed  separately 
without  the  benefit  of  reuse  then  OLP 
does  not  provide  any  cost  savings.  The 
software  tools  available  for  creating  and 
managing  robotic  welding  templates  and 
macros  are  also  highly  specialized  and 
difficult  to  use.  In  order  to  be  cost 
effective  for  shipbuilding  use,  these 
robot  planning  tools  need  to  be  geared 
toward  ease-of-use.  They  also  need  to 
be  focused  on  rapid  program 
modification  and  adaptation  to  support 
the  low  rate,  custom  part  environment 
typical  in  shipbuilding.  The  ideal 
solution  to  these  problems  would  be  the 
automatic  generation  of  welding  paths 
and  procedures  directly  from  the 
geometry  and  material  information 
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contained  in  the  design  model. 
Interoperability  and  standard  data 
formats 

Software  tools  for  robotic  welding  form 
a  very  small  market  segment.  These 
have  typically  been  developed  as 
proprietary  solutions  that  are  tightly 
integrated  with  a  particular  welding 
robot  or  as  welding  applications  built  on 
top  of  generic  robot  control  programs. 
There  are  no  standard  formats  defined 
for  capturing  welding  information  to  be 
used  in  programs,  or  application 
programming  interfaces  (APIs)  to  aid  in 
the  development  of  welding  routines. 
Templates  used  for  programming  a 
particular  welding  system  cannot  be 
easily  applied  to  a  system  from  a 
different  vendor. 

Reuse  of  skill  and  knowledge  resources 

Robots  constitute  a  large  capital 
investment  in  equipment  and  a 
significant  human  resource  investment  in 
the  development  of  knowledgeable  and 
skilled  programmers  and  operators.  It 
may  not  be  practical  to  share  robots 
between  different  application  areas  in 
the  shipyard  such  as  profile  cutting  and 
welding.  However,  there  are  obvious 
savings  in  the  pooling  of  staff  resources 
associated  with  robotics  in  all 
application  areas.  The  robots  used  in 
welding  are  the  same  class  of  industrial 
robots  that  are  used  in  other  areas.  The 
programming  and  operation  skills  used 
for  one  application  will  be  almost 
entirely  reusable  in  other  applications. 
Due  to  the  limited  applicability  of  these 
skills,  combining  the  resources  of  all 
those  working  on  robotic  applications 
may  be  the  only  way  to  sustain  a  viable 
group  within  an  organization. 


Specialized  techniques  for  thick  sections 

Most  of  the  automated  welding  systems 
in  place  in  industry  are  doing  straight 
line,  single  pass  welding.  In  order  to 
support  the  thick  sections  required  for 
some  naval  structural  applications,  the 
capability  for  multi-bead,  multi-layer 
(MBML)  welding  must  be  developed. 
Templates  used  for  storing  weld 
procedures  would  need  to  be  modified  to 
capture  information  regarding  the 
sequence  of  weld  beads  and  any  weaving 
motions  required.  Automated  tracking 
systems  would  need  to  recognize  and 
take  into  account  existing  weld  beads 
while  following  the  joint.  Robot  motion 
would  also  need  to  be  programmed  to 
accommodate  for  the  offset  from  the 
joint  centerline  at  the  large  opening  of 
bevels  and  any  weaving  or  side  to  side 
motion  required. 

3.  Testing/Inspection  and  Quality 
Control/Assurance 

Background 

As-built  data  management  entails  the 
processes  for  the  collecting,  analyzing, 
managing  and  publishing  of  data  that 
describes  the  as-built  configuration  of  a 
ship.  It  encompasses  the  areas  of 
accuracy  control  and  reverse 
engineering. 

Accuracy  Control  is  defined  as 
measuring  selected  dimensions  during 
manufacture,  assembly  and  outfitting  to 
allow  in-process  adjustments  to  assure 
the  final  product  meets  design 
requirements,  readily  fits  to  mating 
parts,  and  achieves  system  functional 
needs.  The  goals  of  accuracy  control  are 
to  reduce  the  cost  of  manufacture, 
outfitting,  and  assembly;  improved 
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product  quality;  and  minimize  rework. 
Accuracy  in  cutting  and  fabrication 
reduces  excess  material  and  its  costs. 
Measurement  methods  include  tape 
measures  and  micrometers,  laser 
scanning,  digital  photogrammetry  (both 
with  and  without  targets),  theodolite 
stations,  and  CMM  arms.  Automated 
measurements  that  feed  self-checks  are 
the  most  efficient  implementation  of 
accuracy  control. 

The  NSRP  Benchmarking  Report 
NSRP[2001]  notes  that  European 
shipyards  received  high  marks  for  their 
accuracy  control  processes.  Self¬ 
checking  is  the  nonn  and  in  general 
there  is  a  high  level  of  confidence  in  the 
dimensional  accuracy  of  all  components 
with  the  use  of  excess  material 
minimized  in  most  yards.  However,  US 
yards  are  relatively  weak  in  accuracy 
control,  even  though  accuracy  control  is 
generally  recognized  as  a  valuable 
means  for  eliminating  unnecessary  work. 
Self-checking  and  statistical  accuracy 
controls  are  only  used  to  a  moderate 
level  in  a  few  yards.  This  means  that 
most  units  and  blocks  go  to  the  building 
ways  or  dock  with  excess  material  on  at 
least  one  edge.  They  are  then  fitted  at  the 
building  position,  which  is  costly  both  in 
terms  of  direct  man-hours  and  crane 
hanging  times.  The  lack  of  accuracy  in 
steelwork  also  has  cost  implications  for 
the  installation  and  connection  of  outfit 
systems. 

There  are  emerging  systems 
technologies  that  support  two  major  as- 
built  data  management  use  cases: 
validation  of  as-built  data  to  design 
(accuracy  control)  and  capture  of  as- 
built  data  as  constraints  for  new  design 
(reverse  engineering)  or  for  build-to-suit. 
These  two  use  cases  have  quite  a  bit  of 
overlap;  however  there  are  also 


significant  differences,  which  result  in 
different  technology  requirements.  In  the 
validation  use  case,  the  objective  is  to 
determine  whether  an  as-built  work 
product  conforms  to  the  planned  design. 
The  overall  use  case  consists  of  the 
following  steps: 

-  Identify  the  critical  measurements  that 
need  to  be  taken.  In  this  use  case  the 
process  of  determining  which  are  the 
critical  dimensions  is  dictated  by  the 
design  intent  behind  the  as-designed 
product  model.  This  applies  whether 
the  product  model  is  a  2D  drawing  or  a 
3D  digital  model. 

-  Develop  a  plan  for  collecting  the 
measurement  data  that  has  been 
identified. 

-  Collect  and  integrate  the  data. 
Collection  of  the  data  must  be 
accomplished  in  such  a  way  that  it  can 
be  compared  to  design  product  model. 
The  format  in  which  the  product  model 
has  been  defined  impacts  the  plan  for 
collecting  and  integrating  the  data. 

-Analyze  the  data  and  detennine  any 
corrective  action  that  may  be  needed. 
Analysis  of  the  data  can  only  be 
accomplished  by  aligning 
measurement  data  with  the  product 
model  data.  This  means  that  any  tools 
developed  to  automate  this  analysis 
need  to  be  able  to  process  design  data 
as  well  as  measurement  data. 
-Evaluate  results  and  establish  lessons 
learned:  The  measurement  data,  the 
design  data  and  the  comparison  of  the 
two  need  to  be  stored  and  managed  in 
such  a  way  that  they  can  be  archived 
and  accessed  in  the  future  -  for 
example,  to  identify  trends  in  similar 
scenarios. 
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In  the  reverse  engineering  use  case,  the 
objective  is  to  collect  as-built  data  so 
that  it  can  be  used  to  aid  in  the  design  of 
new  work  products  that  interface  with 
the  measured  items.  One  example  is  the 
build-to-fit  scenario,  in  which  an  item 
needs  to  be  designed  specifically  to  fit 
into  an  assembly  or  area  of  the  ship  that 
has  already  been  constructed.  Another 
example  is  in  the  overhaul  process,  in 
which  design  work  does  not  start  from  a 
blank  page  but  rather  is  dictated  by  the 
as-built  condition  of  the  ship  to  be 
overhauled.  The  overall  use  case  consists 
of  the  following  steps: 

-  Identify  the  critical  measurements  that 
need  to  be  taken.  In  this  use  case  the 
original  design  model  is  less 
important.  In  some  cases  it  may  no 
longer  be  accessible.  The  definition  of 
the  critical  measurements  is  driven  by 
the  new  items  that  need  to  be  designed. 

-  Develop  a  plan  for  collecting  the 
measurement  data  that  has  been 
identified.  In  some  cases  it  is  necessary 
to  capture  a  complete  model  of  the  as- 
built  conditions. 

-Analyze  the  data  and  change  it  to  a 
format  that  can  be  used  in  the  new 
design.  In  this  scenario  the  goal  is  to 
create  a  new  design  not  to  compare  the 
measured  data  to  an  existing  design. 
The  requirement  is  to  export  design 
data  rather  than  to  import  it. 

-For  build-to-suit,  measurement  data  is 
analyzed  to  provide  trade  direction 
such  as  removing  extra  stock,  sizing 
shims  and  building  templates  to  ensure 
dimensions  between  adjacent 
components  are  achieved  without 
rework. 

One  example  is  the  ship  check  process 
for  naval  combatants.  The  goal  of  the 
ship  check  process  is  to  acquire,  manage 


and  analyze  information  resulting  from  a 
physical  examination  of  an  existing  ship. 

State  of  the  art 

Traditionally  the  collection  and  analysis 
of  as-built  data  has  been  a  predominantly 
manual  task.  In  many  cases,  it  is  still 
accomplished  with  tape  measures.  Even 
when  automated  measuring  devices  are 
introduced  the  process  of  transcribing 
and  managing  the  measurement  data  is 
not  fully  automated.  Today  there  is  a 
range  of  data  collection  technologies 
available  including  theodolites,  laser 
scanners,  co-ordinate  measurement 
machines  (CMM)  and  photogrammetry. 
Each  collection  technology  has 
particular  strengths  and  weaknesses. 

Theodolites 

A  theodolite  system  is  an  optical 
measurement  system  by  which  operators 
map  and  record  data  points  to  a 
computer  for  later  use.  The  system  uses 
a  number  of  theodolite  heads  linked  to  a 
computer  to  triangulate  the  position  of 
data  points.  This  technology  results  in  a 
very  accurate  measurement  of  individual 
data  points,  but  is  too  time  consuming  to 
be  used  when  a  very  large  number  of 
measurements  are  needed.  A  leading 
theodolite  organization  is  the  IMTEC 
Group.  Details  for  this  organization  may 
be  found  at  http://www.imtecgroup.com/ 

Laser  scanners 

A  second  data  collection  technology  is 
laser  scanning.  Laser  scanning  is  a 
convenient  method  for  collecting  a  large 
number  of  points  on  a  surface.  A  hand 
held  scanner  can  be  used  to  measure 
small  objects;  a  mounted  scanner  is  used 
for  measuring  a  compartment’s  worth  of 
data.  A  small  number  of  targets  may  be 
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used  to  enhance  the  quality  of  the 
measurement.  Laser  scanners  capture  a 
large  number  of  data  points  on  the 
surfaces  of  the  objects  scanned.  This 
data  structure  is  typically  referred  to  as 
“point  cloud.”  This  approach  is  well 
suited  to  large,  relatively  smooth 
surfaces  such  as  the  hull  of  a  ship. 
Recently  there  has  been  interest  in  the 
use  of  laser  scanners  for  use  cases  such 
as  ship  checks.  There  are  some 
limitations  inherent  in  the  application  of 
this  technology  in  this  kind  of  scenario. 
The  laser  scanner  only  records  data  for 
surfaces  that  face  the  scanning  device. 
Currently  it  is  not  feasible  to  capture 
surfaces  that  face  away  from  the  scanner 
or  that  are  blocked  by  other  objects.  This 
limits  the  usefulness  of  the  technology 
for  applications  such  as  ship  checking. 
Another  limitation  is  the  difficulty  of 
generating  surface  models  from  point 
cloud  data.  The  conversion  of  points  to 
surfaces  is  particularly  difficult  when  the 
measured  surfaces  have  many  edges  and 
other  singularities.  These  are  the 
conditions  that  are  typically  encountered 
when  trying  to  capture  an  arrangement 
with  a  ship  compartment.  The  volume  of 
data  (number  of  points)  is  too  large  to 
process  in  its  own  right;  yet  considerable 
effort  is  needed  to  interpret  the  data.  The 
interpretation  of  the  data  can  either  take 
the  fonn  of  fitting  a  mesh  to  the  surface 
or  of  comparing  the  points  to  a  known 
CAD  representation.  Both  processes  are, 
today,  only  partially  automated  and  still 
require  extensive  effort.  In  some  system 
the  point  cloud  is  used  to  assist  an 
operator  in  the  creation  of  a  wireframe 
model.  That  wireframe  model  is  then 
used  to  speed  up  the  process  of  creating 
a  solid  or  surface  model.  For  data  with 
few  singularities,  a  point  cloud  can 
usually  be  converted  fairly  easily  to  a 
surface  model.  The  problem  is  that  most 


CAD  platforms  today  deal  primarily 
with  solids,  and  there  is  no 
straightforward  way  to  match  surface 
models  with  solid  models.  For  data  with 
many  singularities,  the  problem  is  to 
identify  the  edge  and  boundaries  of 
objects.  Today  this  is  still  a  manual 
process.  Information  on  leading  laser 
products  and  services  can  be  found  at  the 
following  URLs: 

http://www.inovx.com/home.html 

http://www.cyra.com/home/home.html 

http  ://www.  solexperts.com/  e-leica- 

totalstation.pdf 

http://www.lewisinstrnments.com/totalstation.htm 

http://www.3rdtech.com/DeltaSphere.htm 

Coordinate  measurement  machines 
(CMM) 

Another  style  of  measurement  system 
employs  the  use  of  touch  probes  to 
measure  inspection  features  related  to  a 
physical  object.  This  approach  is  more 
discriminating  than  the  laser  scanning 
approach;  it’s  objective  is  to  enable 
meaningful  comparisons  to  design  intent 
or  the  creation  of  new  design  features. 
One  family  of  such  devices  is  the 
portable,  measurement  arm.  These 
devices  support  the  collection  of  a  point 
at  a  time  by  means  of  touching  the 
measured  object.  Although  it  represents 
an  advance  over  the  collection  of 
measurement  data  with  tape  measures, 
there  are  some  drawbacks  to  the 
approach.  Even  though  it  is  based  on  the 
process  of  touching,  it  has  difficulty 
measuring  points  and  lines  directly.  A 
point  is  measured  by  touching  the  probe 
at  the  desired  location.  Of  course,  such 
an  operation  is  subject  to  operator  error; 
the  probe  may  be  placed  slightly  off 
location.  This  is  compensated  for  by 
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taking  multiple  measurements  at  the 
same  point  and  averaging  the  result. 
Similar  difficulties  are  associated  with 
the  measurement  of  straight  lines.  In 
many  shipbuilding  applications,  the 
measurement  of  small  number  of 
strategically  located  points  is  all  that  is 
needed.  For  example,  the  size  and  shape 
of  cut  steel  plate  can  be  determined  by 
locating  its  vertices.  With  a  touch  probe, 
this  is  best  accomplished  by  finding  the 
planes  of  the  adjoining  surfaces  and 
computing  the  intersecting  point. 
Leading  measurement  product 
information  may  be  found  at  the 
following  URLs: 

http://www.faro.com/Default.asp 

http://128.121.176.37/main/index.php 

Close  range  digital  photogrammetry 

This  approach  has  many  similarities  to 
the  laser  scanning  approach.  However,  it 
is  more  heavily  dependent  on  the  use  of 
targets.  Pre-measured,  known  target 
locations  require  considerable  set-up 
time.  For  scenarios  such  as  ship 
checking,  this  set  up  time  can  be 
prohibitive.  Photogrammetry  is  better 
suited  for  the  measurement  of  a  single 
object  at  a  time  or  for  scenarios  in  which 
targets  can  be  set  once  and  re-used  for 
multiple  measurements.  For  example,  it 
may  be  used  to  detect  variations  in  a 
manufacturing  process  that  is  supposed 
to  be  consistent  for  repeated  instances.  A 
second  scenario  entails  the  use  of  close 
range  photogrammetry  for  measuring 
objects  that  have  certain  characteristics 
that  simplify  the  translation  of  point  data 
to  meaningful  inspection  results.  The  big 
advantage  of  such  a  capability  is  that  the 
set-up  time  is  minimized  and  in  some 
cases  eliminated.  Operator  intervention, 
such  as  that  required  with  a  touch  probe, 


is  eliminated.  This  means  that  more 
items  can  be  effectively  measured  and 
checked  automatically  without  operator 
intervention. 

Integrated  metrology  systems 

Most  metrology  tools  today  are 
accompanied  with  their  own  software  for 
managing,  analyzing  and  storing 
measurement  data.  This  has  the 
advantage  that  the  software  can  be 
tailored  to  the  particular  measuring 
device.  However,  there  are  drawbacks. 
Shipyards  are  required  to  learn  and 
support  multiple  software  packages,  and 
interoperability  between  the  software 
packages  is  very  limited.  A  newly 
emerging  approach  is  the  integrated 
metrology  software  package,  which  is 
capable  of  acquiring  data  from  any 
combination  of  collection  devices.  This 
approach  has  several  advantages.  First, 
there  is  a  core  set  of  functionality 
required  for  the  analysis,  management 
and  reporting  of  measurement  data. 
There  is  no  reason  the  functionality  has 
to  be  duplicated  for  each  new  type  of 
measurement.  A  consolidated  system 
simplifies  the  training  and  support 
requirements  for  the  shipyard;  a 
common  user  interface  can  be  used  with 
different  devices.  Moreover,  such  an 
approach  supports  the  use  of  dynamic, 
collaborative  sessions  in  which  the 
measurements  from  various  devices  can 
be  combined  in  a  single  presentation. 
Tool  information  may  be  found  at 
http://www.mrcday.com/spatial  analyzer.htm 

Technical  challenges 

Automation  of  the  accuracy  control 
processes  relies  heavily  on  the  concept 
to  the  “point-reducible  feature.”  A  point- 
reducible  measurement  feature  is  a 
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meaningful  design  abstraction  that  can 
be  defined  completely  by  one  or  more 
geometric  points.  A  measurement 
feature  consists  of  a  geometric 
component,  a  description  of  design 
intent  and  information  regarding 
acceptable  tolerance.  To  a  certain  extent 
measurement  features  are  constrained  by 
the  technology  that  currently  supports 
their  definition.  Measurement  results 
consist  of  measured  geometric  points 
arranged  in  a  meaningful  manner.  One 
of  the  biggest  technical  challenges  to  the 
automation  of  accuracy  control 
processes  is  the  association  of 
measurement  features  to  the 
corresponding  design  features.  As  noted 
above,  today's  shipbuilding  CAD 
systems  do  not  support  a  systematic 
approach  for  capturing  of  design 
features.  This  is  a  prerequisite  for 
automated  accuracy  control.  Moreover, 
today’s  metrology  systems,  even  the 
integrated  ones,  each  use  their  own 
proprietary  feature  set.  An  integral  part 
of  the  accuracy  control  use  cases  is  the 
comparison  of  measurement  data  to  the 
as-planned  product  model.  The  accuracy 
control  system  needs  to  be  able  to 
represent  both  product  model  geometry 
and  measurement  geometry.  Some 
systems  make  a  distinction  between 
points  (from  the  product  model)  and 
targets  (points  collected  from  a 
measurement  device). 

A  second  technical  challenge  involves 
the  ease  of  use  of  automated  metrology 
tools.  There  are  clear  advantages  to  the 
use  of  advanced  measurement  devices 
over  the  use  of  tape  measures  and 
micrometers.  However,  in  some  cases 
the  new  tools  are  so  difficult  to  master 
that  their  usage  is  limited.  Today’s  tools 
aspire  to  be  general-purpose 
measurement  tools.  As  such  there  is  a 


burden  placed  on  the  operator  to  master 
a  number  of  geometric  principles.  For 
example,  the  first  step  in  many  of 
today’s  systems  entails  the  reconciliation 
of  the  coordinate  system  of  the 
measurement  device  to  the  coordinate 
system  of  the  CAD  model. 

Another  technical  issue  involves  the 
availability  of  critical  dimensions  in  the 
product  model.  Most  automated 
accuracy  control  systems  support  a  best- 
fit  function  that  can  align  coordinate 
systems  based  on  the  manual  selection  of 
key  points  in  the  product  model  to  key 
measure  points.  However,  as  noted 
above,  today’s  shipbuilding  CAD 
systems  do  not  provide  an  adequate 
capability  for  the  capturing  of  critical 
dimensions. 

Finally  automated  accuracy  tools  need  to 
address  the  issue  of  uncertainty. 
Measurements  are  never  totally  free  of 
error.  The  tool  needs  to  be  able  to 
quantify  the  expected  magnitude  of  such 
error  in  order  to  support  meaningful 
comparisons  to  the  product  model. 

Opportunities 

This  section  describes  some  areas  in 
which  new  systems  technologies 
capabilities  could  improve  the  efficiency 
to  the  as-built  data  management 
processes: 

Matching  inspection  features  with  design 
features 

The  ability  to  match  inspection  features 
with  design  features  is  a  pre-requisite  for 
the  automation  of  accuracy  control 
processes.  There  are  actually  a  number 
of  enablers  that  are  needed  to  support 
this  ability.  First,  shipbuilding  CAD 
tools  need  to  be  enhanced  to  be  able  to 
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capture  an  industry-standard  set  of 
design  features.  Work  has  begun  in  some 
disciplines  such  as  piping  and  in  the 
STEP  shipbuilding  standards,  but  in 
general  the  CAD  industry  does  not  yet 
support  this  requirement.  In  fact,  the 
tools  that  support  the  importing  of  CAD 
geometry  into  metrology  systems  are 
inadequate.  Many  systems  support  only 
older  data  exchange  formats  such  as 
IGES.  Typically,  only  geometric  data  is 
imported.  There  is  no  way  to  relay 
critical  infonnation  regarding  design 
intent.  It  is  often  necessary  for  an 
operator  to  manually  filter  the  imported 
geometry  to  remove  a  large  volume  of 
extraneous  geometry. 

In  addition,  metrology  systems  need  to 
support  an  industry-standard  set  of 
inspection  features.  An  industry  standard 
set  of  inspection  features  is  under 
development  within  the  automotive 
industry  by  the  Metrology 
Interoperability  Consortium,  and  this 
work  should  be  extended  to  support  the 
shipbuilding  industry.  After  the  two  sets 
of  industry-standard  features  are 
implemented,  there  is  the  further 
requirement  for  a  computer-interpretable 
means  for  associating  instances  from 
each  set.  The  objective  should  be  the 
creation  of  a  product  model  in  which 
each  critical  design  feature  is  associated 
with  an  inspection  which  designates  how 
the  as-built  condition  of  the  reference 
should  be  measured  and  how  the 
inspection  results  are  to  be  compared 
with  the  design  model.  Care  must  be 
taken  to  keep  inspection  features  loosely 
coupled  to  the  design  product  model. 
Measurement  features  may  vary  from 
shipyard  to  shipyard  and  must  remain 
separable  from  the  design  model. 


Product  data  management  for  as-built 
data 

In  today’s  system  measurement  data  is 
not  adequately  integrated  with  the  design 
product  model  data.  Measurement  data  is 
typically  managed  in  file  systems,  often 
within  documents  such  as  word 
processing  documents  or  spreadsheets, 
which  are  not  linked  to  enterprise  data 
management  systems.  Some  metrology 
systems  utilize  database  management 
system,  but  for  the  most  part  these  are 
also  isolated  systems.  In  fact, 
measurement  data  is  often  treated  as  a 
transient,  rather  than  a  persistent  asset.  A 
point  is  located  on  the  hull  in  order  to 
accomplish  an  installation  process,  and 
there  is  no  further  need  to  store  it.  In 
order  to  get  the  full  benefit  from  more 
sophisticated  and  more  efficient  as-built 
data  collection,  it  is  necessary  to  have 
the  means  to  associate  the  measurement 
data  with  the  pertinent  design  instances. 
In  order  to  accomplish  this,  a  full- 
fledged  product  data  management 
capability  is  needed.  On  the  one  hand, 
the  trend  is  that  shipbuilding  product 
model  data  is  managed  within  some  sort 
of  PDM  environment.  The  PDM 
environment  handles  such  things  as 
configuration  management  (including 
effectiveness),  approvals,  process 
control,  work  requests  and  work  orders. 
These  capabilities  need  to  be  extended  to 
measurement  data.  There  should  be  a 
capability  in  which  measurement  results 
(consisting  of  one  or  more  populated 
measurement  features)  can  be  stored  and 
configuration  managed.  The  system 
must  support  references  into  the 
enterprise  PDM  environment  so  that 
measurement  objects  can  be  associated 
with  the  appropriate  (configuration 
controlled)  product  instances. 


38 


General  purpose  vs.  specialized 
inspection  tools 

Today’s  generation  of  measurement 
tools  and  systems  strive  to  be  general 
purpose,  satisfying  the  broadest  possible 
range  of  metrology  needs.  However,  the 
general-purpose  nature  of  these  tools 
sometimes  make  them  prohibitively 
difficult  to  use  for  simple  and/or 
frequently  repeated  tasks.  Many  of  the 
measurement  tasks  that  are  required  in 
the  shipbuilding  industry  can  be 
categorized  and  specialized  into  a 
relatively  small  set  of  families  of  tasks. 
The  shipbuilding  industry  should  be 
proactively  defining  its  specific  as-built 
use  cases.  These  use  cases  should 
become  the  foundation  for  a  set  of 
requirements  that  is  presented  to 
metrology  system  vendors  as  well  as  to 
international  standards  bodies. 

A  significant  advantage  of  such  a 
specialization  is  that  some  families  of 
measurement  tasks  can  take  advantage 
of  constraints  inherent  in  the  use  case 
itself  in  order  to  simplify  the  task  so  that 
it  can  be  more  completely  automated. 
For  example,  in  today’s  systems,  the 
accuracy  control  use  case  entails 
significant  operator  intervention  to  align 
the  measurement  and  product  co¬ 
ordinate  systems.  In  some  use  cases 
there  are  sufficient  hints  in  the  procedure 
for  data  collection  so  that  the  co-ordinate 
system  alignment  can  be  computed 
automatically.  Some  systems  provide 
programming  macros  that  can  be  used  to 
support  such  specialization.  However,  a 
more  comprehensive  and  reusable 
approach  would  be  to  define  explicitly  a 
standard  set  of  shipbuilding  use  cases 
and  to  provide  functions  to  support  each 
one. 


A  good  case  in  point  is  accuracy  control 
for  the  cutting  of  steel  plates  and  the 
cutting  of  sheet  metal  shapes.  Both 
problems  are  essentially  flat  pattern 
problems,  and  many  simplifications  can 
be  exploited  as  a  result.  For  example,  a 
flat  pattern  is  more  amenable  to  digital 
photogrammetry.  It  is  a  much  simpler 
problem  to  detect  planar  edges  and 
vertices  than  the  detect  boundaries  in 
three-dimensions.  For  this  type  of 
measurement,  there  is  enough 
information  already  in  the  collected  data 
to  align  the  measurement  and  the  design 
coordinate  systems.  In  fact,  it  is 
conceivable  that  the  process  of  assessing 
the  accuracy  of  a  cut  steel  plate  or  flat 
sheet  metal  piece  can  be  totally 
automated.  The  piece  is  photographed; 
the  image  transmitted  to  the  metrology 
system,  which  detects  the  edges  and 
coverts  the  data  to  a  set  of  measurement 
features.  The  system  located  the 
corresponding  design  model,  which 
consists  of  the  appropriate  design 
features.  The  software  analyzes  both 
data  sets  and  computes  the 
transformation  to  align  the  coordinate 
systems  -  aligning  the  associated 
features  at  the  same  time.  Each 
measurement  feature  is  compared  to  its 
corresponding  design  feature.  This 
approach  has  significant  potential  for 
eliminating  set  up  time;  the  number  of 
pieces  that  can  be  measured  increases 
tremendously;  there  is  a  better 
opportunity  for  meaningful  statistical 
process  control.  Without  the 

simplifications  that  result  from  the 
special  characteristics  of  the 

measurement  task  itself,  many  of  those 
automated  steps  would  not  be  possible. 

Feature  recognition  from  point  clouds 
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Automatic  feature  recognition  from 
point  clouds  has  been  a  technical 
challenge  that  has  eluded  researchers  for 
a  long  time.  Nevertheless,  automatic 
feature  recognition  is  a  pre-requisite  for 
the  effective  use  of  point  cloud  data  for 
the  shipbuilding  industry.  As  we  have 
seen,  processes  that  rely  on  measurement 
data  can  be  automated  only  after  useful 
measurement  features  have  been  defined 
and  implemented.  In  the  systems  we 
have  looked  at  so  far,  it  requires  either 
operator  intervention  or  specialized 
restrictions  that  account  for  the  creation 
of  measurement  features.  3D  scanners 
use  laser  technology  to  capture  physical 
objects  such  as  structures  or  scenes  and 
convert  them  into  digital  point  cloud 
data  (3D  coordinates  of  points  in  the 
cloud  relative  to  the  scanner).  This  point 
cloud  contains  a  huge  amount  of  points 
and  specialized  software  is  required  to 
manipulate  and  reduce  the  point  cloud 
data  to  extract  the  feature.  Technology 
currently  exists  to  convert  a  ‘cloud  of 
points’  acquired  from  laser  scans  into  a 
simplified  3D  model.  This  simplified 
model  is  a  3D  surface  model  which  is 
converted  from  the  thousands  of  laser 
scanned  points  into  an  optimized  CAD 
model,  automatically.  The  surface 
model  essentially  ‘connects  the  dots’ 
with  poly-mesh  3D  CAD  geometry. 
This  optimizes  the  size  and  shape  of  the 
geometry  by  eliminating  redundancy  to 
significantly  reduce  the  file  size  when 
compared  to  the  original  laser  scan 
cloud.  The  accuracy  of  the  3D  CAD 
geometry  depends  on  the  accuracy  of  the 
scanned  point  cloud  data.  The 
meaningfulness  of  this  data  is 
compromised,  however,  because  of  its 
lack  of  features.  Today,  the  only  way  to 
associate  particular  points  in  the  point 
cloud  with  measurement  or  design 


features  is  through  tedious  operator 
intervention. 

Improved  means  for  processing  critical 
dimensions 

As  we  have  seen  above,  there  is  a 
recognized  need  to  enhance  shipbuilding 
CAD  systems  so  that  they  represent 
critical  dimensions.  By  the  same  token, 
automated  accuracy  control  systems  will 
need  to  be  able  to  process  these  new  data 
structures.  Critical  dimensions  are  an 
essential  part  of  the  algorithms  that  will 
be  used  to  align  measurement  with 
design  coordinate  systems.  Measurement 
data  cannot  be  compared  to  design  data 
unless  both  are  situated  in  the  proper 
context. 

Visualization  tools 

Improved  scientific  visualization  tools 
will  be  needed  in  order  to  take  full 
advantage  of  digital  as-built  data 
management  capabilities.  It  must  be  easy 
to  recognize  trends  and  ramifications 
from  an  examination  of  as-built  and  it’s 
associated  CAD  data.  Simple  overlays 
are  not  sufficient.  New  techniques  are 
needed  that  illustrate  well  such  concepts 
as  confidence  intervals,  critical  vs.  non- 
critical  dimensions,  and  tolerances. 

Standards  for  the  interoperability  of  as- 
built  data 

As-built  data  will  need  to  be 
interoperable  with  a  number  of  other 
systems,  including  CAD  systems  that 
represent  the  as-planned  model,  various 
metrology  systems  that  need  to  integrate 
the  date,  product  data  management 
systems  that  coordinate  and  manage 
configuration  of  the  data,  and  logistics 
support  systems  that  rely  on  as-built 
configuration  data.  Today  there  are  no 


40 


such  standards.  Measurement  data  is 
‘shared’  only  by  exporting  text  files  in 
non-standard  formats.  The  National 
Institute  of  Standards  and  Technology 
(NIST)  has  begun  work  on  an  ISO-STEP 
standard  for  the  representation  and 
sharing  of  inspection  and  measurement 
data.  The  work  is  being  done  by  the 
Dimensional  Inspection  Infonnation 
Exchange  Project.  The  plan  is  to  produce 
an  international  standard  (ISO  10303- 
219)  which  integrates  with  the  STEP 
product  data  models,  such  as  those  that 
support  shipbuilding.  This  work  has 
been  sponsored  so  far  by  the  automotive 
and  aerospace  industries.  The  U.S. 
shipbuilding  industry  should  support  this 
activity  and  ensure  that  its  special 
requirements  are  addressed  in  the 
international  standard. 

Build  to  fit/reverse  engineering 

Digital  as-built  information  can  also  be 
used  for  build  to  fit  use  cases.  In  order  to 
support  this  capability  tools  need  to  be 
developed  which  can  convert 
measurement  data  directly  to  a  usable 
CAM  format.  In  the  short  term  this 
would  mean  the  generation  of  M&G 
machine  code  from  measurement  data. 
In  the  long  tenn  measurement  features 
could  be  used  to  generate  new  design 
features.  These  design  features  would  be 
used  in  applications  such  as  STEP-NC 
controllers  to  automatically  generate 
CNC  work  plans. 

4.  High-Level  Resource  Planning: 
ERP  Capabilities  (SAP,  Oracle) 

Background 

This  section  describes  the  requirements 
and  capabilities  of  Enterprise  Resource 
Planning  (ERP)  systems  for  the 


shipbuilding  industry.  ERP  is  a  critical 
capability  for  the  shipbuilding  industry. 
ERP  entails  the  management  and  control 
of  shipyard  production  processes  at 
virtually  every  level.  This  includes 
material  management  (from  purchasing 
to  inventory  control);  work  planning 
(from  schedules  to  work  orders); 
personnel  (from  resources  to 
qualifications);  and  as-planned  product 
data  (from  bill  of  material  to  the 
management  of  joints).  As  with  other 
systems  technologies  that  we  have 
examined,  the  shipbuilding  industry  is  in 
the  unfortunate  position  of  having 
special  and  extensive  requirements  but 
only  a  minor  market  share  among  ERP 
vendors.  The  first  generation  ERP 
systems  were  oriented  toward  process 
industries  and  repetitive  discrete 
manufacturing  processes.  The 
production  processes  in  the  shipbuilding 
industry  are  built  to  order  processes. 
Moreover,  there  is  very  little  repetitive 
manufacturing.  Even  though  many  ships 
are  instances  of  a  class,  there  is  a 
substantial  interval  between  the 
repetition  of  a  task  on  each  hull.  In  that 
interval  it  is  not  unusual  for  design  or 
production  changes  to  have  occurred. 
The  shipbuilding  production  processes 
are  more  akin  to  construction  processes 
than  to  the  repetitive  processes  found  in 
the  automotive  industry.  Support  for 
these  kinds  of  processes  have  eventually 
been  incorporated  into  ERP  systems,  but 
they  are  not  always  aligned  with  the 
original  functional  capabilities. 

ERP  systems  seek  to  cover  as  much 
ground  as  possible  and,  thus,  support  a 
number  of  different  production  processes 
and  business  processes.  These  include: 

Bill  of  material  (BoM):  The  ERP  system 
manages  hierarchical  structures  of  items. 
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These  items  are  most  often  the 
component  parts  of  the  ship,  but  they 
could  also  be  equipment,  functional 
locations,  documents  and  sales  orders. 
For  each  item,  the  BoM  designates  such 
data  as  name,  quantity,  and  unit  of 
measure.  The  BoM  supports  material 
management,  staging  of  material  for 
production  and  costing  -  for  new 
construction  as  well  as  for  maintenance. 

Master  planning:  This  function  defines 
production  quantities  for  stated  intervals. 
This  includes  material  forecasting  (using 
known  rates  of  consumption  to  forecast 
needs),  demand  management  (defining 
future  requirements  for  finished 

products),  master  production  scheduling 
(marking  certain  parts  for  special 
schedule  attention),  and  long-term 
planning.  These  are  the  functions 
typically  associated  with  master 

planning  in  an  ERP  system.  It  should  be 
clear  that  there  is  not  a  good  match 
between  the  provided  capabilities  and 
shipbuilding  processes. 

Capacity  planning:  This  function 
established  available  capacities  in 

relation  to  production  requirements. 
Capacity  planning  can  be  computed  for 
long-tenn,  mid-term  or  short-term 
planning.  It  consists  of  scheduling, 
calculating  capacity  loads,  evaluating 
capacity  and  leveling. 

Material  Requirements  Planning:  This 
function  supports  the  availability  of 
material  for  sales  as  well  as  for 
production.  It  deals  with  monitoring  and 
replenishing  stocks  by  scheduling  timely 
purchasing  and  production,  usually  by 
automatically  creating  purchase  orders 
or  work  orders. 


Production  Orders:  This  function  is  also 
known  as  shop  floor  control.  It  provides 
the  specification  of  what  is  to  be 
produced  and  on  what  dates.  It  also 
designates  locations  and  costs.  It  also 
provides  the  means  to  associate  a  routing 
with  a  work  order.  Subsequently,  the 
BoM  is  exploded,  and  material  and 
resources  are  reserved.  It  detennines 
planned  costs  and  identifies  non-stock 
components  and  external  requirements. 

State  of  the  art 

Today  one  vendor  dominates  the  ERP 
domain  among  shipbuilders.  Even 
though  there  are  a  number  of  well- 
established  ERP  vendors  (including 
Oracle),  most  shipyards  are  leaning 
toward  SAP  as  the  favorite.  Currently, 
every  major  shipyard  has  an  ERP/MRP 
capability.  Some  are  highly-customized 
MRP  systems.  These  systems  are 
typically  built  on  technology  that  is 
dated  and  is  cumbersome  in  many 
respects  -  from  the  underlying 
programming  language  to  the  database 
technology.  Such  systems  are  difficult  to 
extend  and  interoperability  with  such 
systems  is  not  well  supported.  The 
problem  is  that  such  systems,  as  a  result 
of  considerable  customization,  now  meet 
the  functional  ERP  needs  of  the 
shipyard.  Experience  has  shown  that  the 
deployment  of  an  ERP  capability  at  a 
shipyard  is  a  monumental  undertaking, 
and  its  success  is  by  no  means  assured. 

Deployment  of  an  ERP  capability  is 
complicated  by  a  number  of  issues, 
including  the  lack  of  competition,  the 
extensiveness  of  ERP  functionality  and 
the  need  for  the  integration  of  several 
capabilities  in  order  to  support  ERP 
needs.  In  addition,  ERP  systems  support 
mission-critical  functions  within  the 


42 


shipyard.  As  a  result,  even  though  there 
is  a  single  vendor  that  is  generally 
preferred,  there  are  still  hurdles  to 
successful  deployment.  These  hurdles 
are  both  technical  and  cultural.  On  the 
technical  side,  the  SAP  application, 
because  of  technical  as  well  as 
competitive  drivers,  is  a  monolithic 
system  built  upon  a  single  common  data 
model.  Its  modules  are  tightly  coupled 
with  each  other  and,  thus,  discourage  the 
use  of  modules  from  other  vendors.  The 
scope  of  the  application  is  very  broad, 
and  the  prospects  of  significant  changes 
to  the  existing  code  base  are  slight.  The 
tool  itself  imposes  certain  processes  on 
the  shipyard,  and  as  we  have  seen,  the 
processes  that  come  out  of  the  box  do 
not  always  provide  a  nice  fit  with 
shipbuilding  requirements.  For  example, 
the  configuration  management  capability 
in  SAP  provides  considerable 
capabilities  to  support  variants  and 
production  of  lots.  Configuration 
management  requirements  for 
shipbuilding  do  not  make  much  use  of 
these  capabilities.  In  the  end,  the 
shipyard  must  either  change  its  process 
to  accommodate  the  ERP  system  or 
jerry-rig  a  solution  that  bridges  the  gap. 

Another  problem  with  current  ERP 
capabilities  is  the  lack  of  standards  that 
support  information  sharing  to  and  from 
the  ERP  system.  Ten  years  ago  the  same 
problem  faced  CAD  systems,  but  steady 
progress  in  the  STEP  arena  has  changed 
that.  The  situation  is  not  as  promising  for 
ERP  information  sharing.  One  factor  has 
been  that  the  information  in  the  ERP 
system  is  viewed  as  less  re-usable  than 
the  design  product  model  data.  There  are 
fewer  potential  users  of,  say,  a  work 
order  than  of  a  system  diagram.  Another 
factor  is  that  there  are  so  few  ERP 
vendors.  The  argument  can  be  made  that 


there  is  less  need  for  information 
sharing.  Nevertheless,  there  have  been 
some  efforts  to  standardize  the  sharing 
of  ERP  information.  Most  of  this  activity 
has  taken  place  in  the  context  of 
business-to-business  e-commerce.  The 
first  generation  standards  were  EDI  and 
EDIFACT.  Both  of  these  standards 
emphasized  business  transactions  as  well 
as  infonnation  sharing.  As  a  result  the 
standards  became  bulky  and  expensive 
to  deploy.  Most  shipyards  have  looked  at 
the  standards,  but  they  have  not  been 
widely  adopted  among  the  U.S. 
shipyards.  The  current  activity  is  focused 
on  the  development  of  an  XML-  and 
Web-based  approach  to  e-commerce. 
Today  most  shipyards  have  invested  in 
non-standard  solutions.  Several 

competing  proprietary  XML  business 
languages  have  been  proposed;  some 
industry  consortia  have  been  fonned  to 
promulgate  industry-specific  languages. 

Currently,  the  most  active  group 
addressing  e-business  standards  is  the 
Organization  for  the  Advancement  of 
Structured  Information  Standards 
(OASIS).  OASIS  is  a  not-for-profit, 
global  consortium  that  drives  the 
development,  convergence  and  adoption 
of  e-business  standards.  The  OASIS 
consortium  employs  an  open  process  by 
which  its  members  promote  industry 
consensus  and  attempt  to  harmonize 
disparate  efforts.  OASIS  produces  de 
facto  worldwide  standards  for  “security, 
Web  services,  XML  conformance, 
business  transactions,  electronic 
publishing,  topic  maps  and 
interoperability  within  and  between 
marketplaces”.  One  of  the  standards 
being  developed  is  the  Universal 
Business  Language  (UBL).  The  purpose 
of  the  UBL  is  to  provide  a  standard 
library  of  XML  business  documents 
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(purchase  orders,  invoices,  etc.)  by 
modifying  an  already  existing  library  of 
XML  schemas.  UBL  is  intended  to 
become  an  international  standard  for 
electronic  commerce  freely  available  to 
everyone  without  licensing  or  other  fees. 
However,  like  its  predecessors,  UBL  is 
currently  focused  on  business 
documents,  including  purchasing 
documents,  materials  management 
documents,  payment  documents  and 
catalogs.  The  focus  is  on  business-to- 
business  interactions.  In  order  to  support 
full  ERP  interoperability,  the  focus 
would  have  to  expand  to  cover  internal 
documents:  work  orders,  schedules, 
plans,  routings,  etc. 

One  of  the  most  ambitious  ERP 
activities  in  the  shipbuilding  domain  is 
the  US  Navy’s  NEMAIS  project,  the  US 
Navy  Enterprise  Maintenance 
Automated  Information  System.  The 
objective  of  the  NEMAIS  project  is  to 
provide  ERP  functionality  across  the 
fleet  and  regional  maintenance  centers. 
The  goal  is  to  replace  the  multitude  of 
systems  that  are  currently  in  place.  The 
technical  approach  is  to  deploy  a  SAP 
system  across  the  participating 
organizations.  Consequently,  the  first 
step  of  the  deployment  is  the 
standardization  of  the  processes  at  each 
organization.  The  standard  process  must 
be  aligned  with  SAP  capabilities.  This 
represents  an  attempt  to  deploy  an 
integrated  approach  (rather  than 
interoperable  approach).  The  idea  is  to 
enforce  the  use  of  a  single  system  using 
a  shared  database  with  a  single 
information  model.  One  of  the 
requirements  of  the  NEMAIS  plan  is  that 
it  integrates  with  legacy  systems,  notably 
with  the  ERP  systems  at  the  shipyards. 
At  this  junction,  there  will  be  a 
requirement  for  ERP  information 


interoperability.  Currently  there  is  no 
technical  plan  regarding  the  form  that 
such  information  will  take. 

Opportunities 

Modular  ERP  capabilities 

The  current  generation  of  ERP  systems 
is  built  on  the  philosophy  of  integration 
as  opposed  to  interoperability.  When 
those  systems  were  built,  the  only  viable 
technical  approach  for  uniting  various 
applications  was  by  means  of  a  tight 
integration.  This  approach  had  the 
advantage  that  it  was  the  only  one  that 
worked  at  the  time,  but  its  disadvantages 
are  that  the  resulting  monolithic  system 
is  unwieldy.  It  is  difficult  to  modularize 
such  an  approach  and  make  it  work  with 
other  vendor’s  products.  It  is  difficult  to 
integrate  such  a  system  with  other  tools 
that  are  used  throughout  the  enterprise. 
Recent  advances  in  information 
interoperability  have  changed  the 
landscape  because  enterprise  application 
integration  can  be  implemented  in  a 
more  flexible  way.  Because  ERP 
functionality  is  so  pervasive  and  so 
essential  to  the  operations  of  the 
shipyard,  there  is  a  need  for  more 
modular  ERP  capabilities.  This  approach 
would  facilitate  the  sharing  of  work 
among  shipyards  as  well  as  the 
deployment  of  ERP  capabilities  to 
smaller  shipyards.  Moreover,  a  more 
modular  approach  supports  the  process 
of  adopting  newer  and  more  powerful 
information  technologies  throughout  the 
shipyard. 

Interoperability  of  ERP  and  life-cycle 
support  systems 

The  current  generation  of  ship  designs 
has  been  captured  in  digital  product 
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models  using  Integrated  Product 
Development  Environments.  More  and 
more,  these  product  models  are  based  on 
design  for  production  strategies; 
however,  the  technology  for 
communicating  this  information  to 
construction  and  support  services  is 
lacking.  The  result  is  that  the  full 
benefits  of  the  product  model  are  not 
always  exploited. 

The  need  exists  for  tools  to  support  the 
sharing  of  ERP  data  that  support 
production  processes  as  well  as  life- 
cycle  support  information.  This  should 
include  interoperability  with  the  product 
model  data  as  supported  by  the 
NSRP/ISE  project.  The  technical 
approach  is  to  build  upon  the  successes 
and  architecture  of  the  ISE  project.  This 
work  should  utilize  international 
standards  such  as  those  being  developed 
by  the  Product  Life-Cycle  Support 
(PLCS)  team. 

The  tools  for  ERP  interoperability  would 
include  tools  to  support  the  following 
life-cycle  support  activities: 

-  Shared  work  packages  across 

organizations.  The  Navy  has 
undertaken  several  initiatives  (in 
particular,  the  NEMAIS  project)  to 
deploy  ERP  capabilities  through  the 
Navy  infrastructure.  Although  much  of 
this  work  centers  around  a  particular 
ERP  product,  there  will  still  be 
requirements  for  an  open  exchange  of 
work  package  infonnation.  This 

requirement  is  even  more  pressing 
when  work  is  shared  with  shipyards  or 
other  organizations  that  have  not 
deployed  the  enterprise  system.  There 
is  significant  overlap  in  the 

information  requirements  for  initial 
construction  and  MRO.  The  tools 


developed  here  would  be  fashioned  to 
support  the  sharing  of  work  packages 
in  both  scenarios. 

-  Integration  of  product  model  data  into 
life-cycle  support  processes.  Currently 
life-cycle  support  is  heavily  dependent 
upon  drawings  and  document-based 
change  orders.  There  is  a  need  for  re¬ 
engineered  processes  that  make  more 
direct  use  of  the  product  model. 

-  PDM  data  typically  is  used  to  initialize 
as-built  and  as-maintained  product 
structures.  There  is  a  need  for  tools  to 
automate  this  process.  New  process 
opportunities  should  emerge  as  a  result 
of  more  accessible  PDM  information. 

-  Today  technical  manuals  are  published 
in  SGML,  but  the  trend  is  clearly 
toward  XML.  There  is  a  need  to 
develop  tools  to  integrate  the  product 
model  and  other  support  data  with 
XML-based  technical  manuals. 

-  Systems  diagrams  are  an  integral  part 
of  the  life-cycle  support  process.  There 
is  a  need  to  make  it  possible  to  share 
piping,  electrical  and  HVAC  diagrams 
with  users  on  the  delivered  ship. 

As-built  and  as-maintained  product 
models 

By  providing  interoperability  between 
the  design/construction  shipyard  and  the 
maintenance  activity  as-built  and  as- 
maintained  feedback  can  be  provided 
and  captured  in  the  product  model 
enabling  100  percent  configuration 
management.  Resultant  benefits 
include: 

-Aid  in  the  development  of  standard 
work  packages  across  private  and 
public  shipyards 

-Eliminate  the  requirement  to  perform 
expensive  shipchecks 
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-  Enable  the  performance  of  more 
accurate  design  studies 

-  Enable  accurate  estimates  for 

modernization  of  shipboard 
technologies 

-Provide  the  ability  to  remotely  plan 
maintenance  activities 

-  Provide  more  accurate  asset  visibility 

-  Enable  real  time  downloads  of 

logistics  products  that  reflect  the  most 

recent  configuration  changes  for 

maintenance  activities. 

-  Support  more  accurate  supply  support 

By  providing  interoperability  among 
design/construction  shipyard  systems, 
the  planning  aspects  of  co-production 
are  supported  and  can  be  extended  to  the 
ship  maintenance,  repair  and  refit 
processes. 

5.  Process  Mapping  and  Simulation 
Background 

Process  Mapping  and  Simulation 
involves  the  use  of  specialized  software 
tools  for  modeling  the  behavior  and 
interaction  of  objects  and  process  steps 
in  a  time  domain.  Traditionally  software 
tools  were  either  good  at  process 
mapping  or  process  simulation,  focusing 
on  knowledge  capture  or  process 
analysis,  respectively.  Today,  most 
process  mapping  tools  have  either 
incorporated  a  simulation  routine  or 
provide  a  link  to  third  party  simulation 
software.  While  process  simulation 
tools  have  enhanced  their  capabilities  to 
also  capture  additional  process  details 
simply  for  recording  knowledge  and  are 
not  necessary  for  simulation.  Process 
mapping  and  simulation  tools  are 
typically  used  to  explore  what-if  type 
analyses,  comparing  "As-Is"  to  "To-Be" 
processes,  feasibility  analysis  of  planned 


conditions,  or  in  the  planning  of 
proposed  implementations. 

Process  mapping  is  most  commonly 
used  for  process  improvement  initiatives 
and  knowledge  capture.  Tools  support 
various  process  mapping  methodologies 
and  techniques,  such  as  IDEF  and  Value 
Stream  Mapping.  IDEF  focuses  on 
knowledge  capture  and  provides  a 
standard  format  to  capture  and  represent 
process  details.  While  Value  Stream 
Mapping  best  supports  process 
improvement  initiatives  by  clearly 
illustrating  value-added  vice  non  value- 
added  process  steps.  Most  process 
mapping  tools  are  flexible  enough  to 
support  various  methodologies  and 
techniques. 

Discrete  Event  Simulation  is  typically 
the  tool  of  choice  for  process  simulation. 
In  these  simulations,  the  time  associated 
with  a  particular  event  is  described  by  a 
random  selection  within  some 
distribution  of  possible  time  values  for 
that  event.  Time  taking  events  can 
represent  the  activity  of  a  machine  or 
operator  performing  a  process  step,  or 
the  movement  of  objects  between 
different  locations.  Elapsed  time  can 
also  can  also  occur  due  to  a  queue  or 
buffer.  Events  have  fixed  dependencies, 
such  as  “process  B  begins  when  three 
items  of  type  A  are  present.”  Multiple 
objects  and  process  steps  are  combined 
into  a  composite  model  that  simulates 
the  perfonnance  of  some  real  life  task  or 
process.  Material  can  be  added  or 
removed  from  the  model  at  any  location 
to  represent  the  flow  of  different 
products  through  the  process  steps. 
Each  time  the  model  is  executed  it  yields 
a  slightly  different  result  time,  which 
falls  within  a  range  of  possible  results. 
The  model  also  keeps  track  of  the 
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amount  and  location  of  material  over 
time.  After  running  the  model  a  number 
of  times,  statistical  analysis  can  be  used 
to  characterize  the  simulated  result  times 
and  material  quantities  at  every  location. 

The  use  of  process  simulation  software 
tools  allows  the  model  to  be  easily 
modified  to  represent  either  desired  or 
unexpected  changes  to  the  process  being 
studied.  The  model  can  be  used  to 
simulate  the  introduction  of  new 
machines  or  process  steps  to  an  existing 
operation.  It  can  also  be  used  to  perform 
what-if  scenarios  to  determine  the 
effects  of  machine  breakdowns  or 
stoppage  in  material  flow.  These 
changes  can  be  easily  accomplished 
through  parameter  settings  in  the 
software  model  and  the  results  can  be 
obtained  quickly  by  re-executing  the 
model. 

Four  different  types  of  analyses  are 
performed  by  process  simulation 
software.  They  are  scheduling,  resource 
analysis,  material  flow,  and  capacity 
planning.  Although  dedicated 

scheduling  and  schedule  optimization 
software  exists,  process  simulation  is 
sometimes  used  to  investigate  the 
feasibility  of  a  proposed  schedule  or  in 
the  development  a  project  schedule.  A 
schedule  can  be  generated  by  using  the 
resulting  simulation  data,  along  with  the 
project  event  dates.  Resource  analysis  is 
the  use  of  a  simulation  tool  to  analyze 
the  utilization  of  resources  -  machines 
and  labor  -  during  a  given  operation. 
High  utilization  of  particular  resources 
may  be  an  indication  of  a  bottleneck  in 
the  overall  process,  thereby  identifying 
the  potential  need  for  large  capital  items. 
Low  utilization  can  be  an  indication  of 
redundant  resources  or  inefficiencies  in 
the  process.  Large  cycles  in  utilization 


can  point  to  critical  events  such  as 
deadlock  conditions  or  extended  waits 
for  a  single  resource  such  as  a  crane 
move.  Process  simulation  can  be  used  to 
study  material  flow.  The  amount  and 
location  of  all  material,  both  source  and 
product,  is  tracked  continuously.  As  the 
simulated  operation  progresses  it  is 
possible  to  see  trends  in  supply  and 
demand  at  different  locations.  The 
effects  of  changes  in  material 
availability  and  distribution  speeds  can 
easily  be  determined.  Another  related 
analysis  is  that  of  capacity  planning. 
Here  the  desired  model  is  established 
and  run  against  a  fixed  or  best-case 
schedule  for  a  given  period  of  time.  The 
overall  output  of  material  during  this  set 
amount  of  time  gives  a  measure  of  the 
operational  capacity.  The  model  can 
then  be  optimized  to  detennine  the 
maximum  process  capacity  or  whether  a 
particular  capacity  level  can  be  achieved. 

State  of  the  Art 

There  are  no  process  simulation  tools 
available  that  are  dedicated  to  the 
shipbuilding  industry  in  particular.  A 
wide  variety  of  process  mapping  and 
simulation  software  is  commercially 
available.  Software  packages  span  a 
broad  range  in  both  cost  and  capabilities. 
Process  mapping  tools  are  relatively 
inexpensive  and  user  friendly.  The  more 
expensive  packages  include  animated 
graphical  output,  sophisticated  statistical 
analysis  capabilities,  and  built-in 
optimization  routines.  Creating  animated 
process  simulation  models  requires  a 
person  with  skills  in  the  general  field  of 
process  modeling  or  operations  research, 
and  a  detailed  knowledge  of  the 
simulation  software  being  used.  Process 
mapping  and  simulation  also  requires 
individuals  with  subject  matter  expertise 
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in  the  specific  process  or  task  being 
studied. 

In  addition  to  process  mapping  and 
simulation,  the  available  software  tools 
possess  some  other  interesting 
capabilities  that  have  yet  to  be  exploited 
in  the  marketplace.  These  additional 
capabilities  include  various  optimization 
engines,  a  schedule  generator,  machine 
process  control,  software  application 
development,  and  electronic  workflow. 
In  some  instances  the  tools  with  these 
additional  capabilities  evolved  to  include 
process  mapping  and  simulation,  and  not 
the  other  way  around. 

One  of  the  process  simulation  tools  that 
has  been  used  in  a  number  of 
shipbuilding  applications  is  ProModel, 
from  ProModel  Corporation.  NASSCO 
has  used  ProModel  to  study  resources, 
material  flow,  and  capacity  planning  at 
their  San  Diego  shipyard.  The  panel  line 
process  was  carefully  modeled  to 
evaluate  resource  utilization. 
Simulations  using  this  model  indicated 
certain  inefficiencies  in  the  existing 
process.  Changes  to  the  process  were 
introduced  in  the  simulation  model  to 
study  their  effects.  As  a  result,  changes 
were  made  in  the  actual  panel  line 
process,  which  improved  overall 
efficiency.  The  shipyard  is  tightly 
constrained  by  surrounding  property  and 
occupies  a  relatively  small  footprint. 
Material  flow  through  the  plate  yard  and 
panel  line  was  studied  to  determine  if 
any  improvements  could  be  made 
through  changes  in  the  layout  of  the  yard 
and  material  transport.  Since  the 
shipyard  could  not  be  expanded 
physically  to  meet  potential  increases  in 
product  demand,  capacity  planning  was 
used  to  detennine  the  maximum  output 
possible  based  on  the  current  size. 
ProModel  proved  to  be  quite  capable  in 


performing  all  of  these  process 
simulation  and  analysis  tasks.  This 
overall  simulation  effort  was  completed 
as  a  team  effort  between  NASSCO 
shipyard  staff  and  outside  consultants 
with  expertise  in  process  modeling  and 
simulation. 

Another  process  simulation  software 
package  that  has  been  demonstrated  in 
shipbuilding  is  QUEST,  from  Delinia. 
QUEST  has  been  used  to  predict 
capacity  and  specify  material  flow  for  a 
new  steel  processing  facility.  Before  the 
new  facility  was  built,  process 
simulations  were  perfonned  to  determine 
the  expected  throughput  of  the  new  plate 
cutting  machine  and  material  handling 
equipment.  These  results  were  used  in 
arriving  at  the  detailed  machine 
specifications.  Simulations  were  also 
used  to  detennine  the  optimum  flow  of 
material  to  the  cutting  machines  and 
between  multiple  lanes  within  the 
facility.  QUEST  provided  all  of  the 
modeling  and  analysis  functionality 
required  for  this  work. 

Lean  manufacturing  initiatives  have 
stimulated  the  use  of  process  mapping 
and  simulation  tools.  The  tools  have 
provided  a  quick  means  to  analyze  the 
difference  between  current  and  proposed 
process  change.  Extend  software  is  a 
two  dimensional  process  modeling  and 
simulation  tool  that  has  been  used  to 
demonstrate  labor  and  span  time  savings 
associated  with  the  process  of  welding 
hull  butts.  Significant  savings  were 
recognized  from  modeling  and  were 
later  validated  with  the  implementation 
of  the  new  process. 

Opportunities 

Standard  for  process  data  definition 
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One  of  the  difficulties  with  process 
simulation  is  that  there  is  no  recognized 
standard  for  capturing  or  exchanging 
process  information.  Process  models 
that  are  created  using  a  particular 
software  tool  cannot  be  readily 
transferred  for  use  with  other  software 
tools.  This  limits  the  possibility  of  reuse 
of  process  models  and  creates  a  barrier 
for  the  spread  of  process  knowledge 
throughout  and  between  organizations. 
Work  is  underway  at  NIST  to  address 
this  problem  through  the  creation  of  an 
information  model  for  processes.  The 
Process  Simulation  Language,  PSL,  is 
intended  to  define  the  data  elements  of 
process  knowledge  and  to  provide  a 
neutral  fonnat  for  exchanging  process 
data  between  applications.  The 
shipbuilding  industry  can  help  in  this 
effort  by  extending  PSL  to  include 
shipbuilding  specific  process 
information  and  by  supporting  pilot  data 
exchange  projects. 

Ease  of  use 

The  work  of  process  mapping  and  the 
use  of  process  simulation  tools  require  a 
high  level  of  skill  and  detailed 
knowledge.  There  needs  to  be  subject 
matter  knowledge  of  the  process  being 
modeled,  an  understanding  of  the  field 
of  process  capture  and  process  modeling, 
and  a  detailed  knowledge  of  the 
simulation  software  used.  Although 
these  knowledge  requirements  may  not 
be  able  to  be  eliminated,  there  is  an 
opportunity  for  the  development  of 
simplified  user  interfaces  to  process 
simulation.  More  work  needs  to  be  done 
in  order  to  allow  the  end  user  to  define 
and  control  the  simulation  without  being 
an  expert  in  process  modeling  or 
simulation  software 


Process  knowledge  and  management 

Traditionally  shipyards  are  good  at 
managing  products  and  the  associated 
sub-processes,  but  have  a  limited  vision 
of  the  global  or  cross-functional 
processes.  Process  mapping  provides  a 
means  to  capture  process  data  at  all 
levels  within  an  organization.  Even 
though  hierarchical  model  building  is 
prevalent  in  many  tools,  few  provide  a 
good  means  to  obtain  aggregate  data  at 
higher  levels.  There  can  also  be  some 
improvements  in  the  way  these  maps  are 
documented,  published,  and  linked. 
Also,  schedule  and  resource  data  are  not 
electronically  linked  to  procedural 
information.  The  simulation  capability 
associated  with  an  optimization  engine 
can  be  used  to  generate  shop  floor 
schedules  based  on  current  conditions; 
resource  availability,  machine  down 
times,  or  procedural  changes.  Using  the 
same  simulation/optimization  engine, 
higher  level  analyses  could  also  yield 
resource  requirements  based  on  products 
and  events.  This  could  support 
manpower  planning  (training,  hiring,  or 
re-allocation),  and  capital  expenditures. 

Process  controls  can  also  be  derived 
from  these  tools  since  they  capture 
routing,  actions  to  performed,  and  span 
times.  Therefore  an  opportunity  exists 
to  automatically  create  electronic 
workflow  systems  based  on  process 
mapping  and  simulation  data.  In 
addition  some  more  work  could  be  done 
to  link  these  tools  with  machine  controls 
to  provide  the  data  they  need  to  perform 
their  functions.  Both  applications  would 
also  provide  the  feedback  necessary  to 
better  measure  and  control  processes. 
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6.  Lean  Manufacturing 
Background 

Traditional  shipyard  process  improvement 
programs  have  often  concentrated  on 
increasing  the  efficiency  of  individual 
manufacturing  operations  (e.g.,  more 
widgets  per  hour  from  a  given  machine, 
reduced  process  lane  cycle  time,  better 
welding  techniques,  etc.),  where  most  of 
the  focus  is  on  improvement  of  touch 
labor  perfonnance.  Lean  Manufacturing, 
on  the  other  hand,  a  body  of  knowledge 
which  originated  in  the  Toyota 
Production  System  (and  which  is  also 
generically  called  Lean  Enterprise  when 
applied  “above  the  shop  floor”),  is  a  total 
business  process  improvement  strategy 
and  suite  of  tools/techniques  centered 
around  the  elimination  of  “non-valued- 
added”  (waste)  activities  from  an  entire 
business’  “value  stream”.  Central  also 
to  the  Lean  philosophy  is  the  pursuit  of 
continuous,  single-piece  flow  of  material 
through  the  manufacturing  process  and 
“pull-based”  process  triggers  for 
material  movement  and  individual 
manufacturing  activity  starts. 

A  key  distinction  of  the  Lean  approach 
is  that  defining  what  constitutes  a 
“value-added”  activity  can  only  be  done 
from  the  paying-customer’s  perspective. 
Value-added  steps,  therefore,  are  only 
those  activities  that  change  form,  fit,  or 
function  of  raw  material  into  the  finished 
product,  or,  in  the  case  of  ship  design 
activities,  those  activities  that  add 
maturity  and  fidelity  to  the  engineering 
design  data.  Because,  by  this  definition, 
most  business  activities  (as  much  as  90- 
95%  in  a  typical  American  corporation) 
are  actually  non-value-added  waste,  the 
Lean  techniques  and  tools  focus 
primarily  on  ways  to  “see”  waste  during 


the  “document  the  current  reality”  phase, 
and  on  ways  to  eliminate  waste  in  the 
“improve”  phase. 

From  the  perspective  of  the  CAD-CAM- 
CIM  environment,  which  would  only  be 
a  small  subset  of  the  Lean  “tool  box”, 
such  waste  analysis  tools  would  include 
functionality  related  to  process  mapping 
and  simulation  (see  the  prior  section  in 
this  paper  for  the  simulation-related 
discussion),  statistical  analysis,  data 
mining,  and  enterprise  cost  analysis.  In 
the  manufacturing  improvement  end, 
however,  the  support  required  to 
implement  Lean  could  be  related  to 
almost  any  of  the  CAD-CAM-CIM 
tools,  including:  enterprise  resource 
planning,  scheduling  and  simulation, 
collaborative  workspace  technologies, 
visualization,  product  data  management, 
manufacturing  tooling  software,  etc.. 
Because  Lean  improvements  can  require 
such  a  smorgasbord  of  solutions,  only 
those  tool  areas  specifically  related  to 
“seeing  waste”  and  those  areas  related  to 
“pull-based”  process  triggers  are 
addressed  in  this  state-of-the-art  report. 

State  of  the  Art 

In  companies  that  are  successful  in 
implementing  Lean,  most  process 
improvement  activities  are  done  in  a 
team  environment  on  an  “event”  basis; 
that  is  to  say,  the  right  players  are  pulled 
off-line,  placed  in  a  room  for  a  week  or 
two,  given  a  skilled  facilitator  who  is 
trained  in  Lean  (and  often  Six  Sigma) 
techniques,  and  told  to  hash-out  a 
complete  solution,  end-to-end.  This 
“this  is  serious”  mentality,  coupled  with 
the  pressure  of  a  pre-scheduled 
executive  out-brief,  dictates  that  the 
analysis  tools  used  by  the  teams  must  be 
quick  and  dirty  and  support  rapid 
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decision  making  based  on  the  best 
available  data.  Process  mapping  is  a 
central  exercise  in  these  team  events,  so 
markers,  sticky  pads,  and  plotter  paper 
(manual  methods)  become  the  order  of 
the  day.  Process  mapping  software, 
when  used,  is  usually  a  luxury,  but  in 
very  complex  projects  can  become  an 
outright  necessity.  Because  of  the  need 
for  speed,  ease  of  use  of  such  software  is 
paramount,  but  is  not  often  found  in 
today’s  software  tools.  General 
Dynamics  -  Electric  Boat  has  used 
Extend  (ImagineThat,  Inc.),  VISEO 
(Microsoft),  and  even  simple  Microsoft 
Powerpoint  slides  for  documenting 
process  maps,  with  the  more  complex 
packages  utilized  when  numerical 
modeling  and  simulation  is  required. 
The  more  complex  tools  require 
specially  trained  users,  which  can  be  a 
scarce  resource  when  many  Lean  teams 
are  deployed  simultaneously. 

Lean  Manufacturing/Enterprise  teams 
also  have  to  quickly  analyze  large 
amounts  of  cost,  schedule,  and  product 
data  about  manufacturing  and  business 
operations  to  determine  root  causes  of 
waste,  rework  cycles,  and  defects.  The 
purpose  of  these  analyses  is  to  justify,  in 
bottom-line,  dollar  and  cycle-time 
savings,  where  to  invest  in  new 
technologies  and  processes.  Because 
lean  (enterprise)  methodology  is  focused 
on  incremental  change,  it  has  a  built-in 
bias  against  revolutionary  change.  The 
focus  is  on  eliminating  unneeded, 
wasteful  steps.  This  type  of  change  does 
not  emphasize  knowledge  of  available 
systems  technologies,  which  is  the 
source  of  revolutionary  process  changes. 
Today,  most  of  this  shipyard  cost, 
schedule,  and  product  information 
resides  in  legacy,  often  proprietary  (and 
sometimes  stand-alone)  databases,  of 


any  manner  of  sophistication,  and  can  be 
hard  to  extract  and  interpret  in  the 
manner  desired  for  a  given  unique 
analysis,  even  by  skilled  users.  When 
data  is  found  to  be  available  and  is 
extracted  in  a  usable  form  (usually 
simple,  tab-delimited  text  extracts), 
statistical  analysis  software  is  utilized. 
This  analysis  software  can  sometimes  be 
as  simple  as  Microsoft  Excel  (with 
statistical  “Add-Ins”),  but  highly  capable 
and  specialized  applications  are  also 
used  when  both  the  software  and  skilled 
statisticians/users  are  available.  A 
number  of  statistical  analysis  software 
packages  have  been  developed  explicitly 
for  Lean  and  Six  Sigma  applications 
(including  such  esoteric  requirements  as 
Design  of  Experiments  and  Response 
Surface  Modeling)  by  the  leading 
consulting  firms  in  the  field;  most  of 
these  products  are  available  for  general 
public  purchase. 

In  the  Lean  “improve”  phase,  “pull” 
systems  are  ultimately  pursued  to  draw 
material  through  the  manufacturing 
cycle  based  on  a  “backward”  flow  of 
triggering  information  (i.e.,  from  a 
customer  demand,  reverse  sequentially 
toward  the  very  first  manufacturing  & 
material  ordering  steps).  This  single- 
piece-flow,  “pull”  philosophy  (versus  a 
batch,  “push”  approach),  is  demonstrated 
to  dramatically  reduce  work-in-process, 
rework  costs,  and  Takt  time  (the  rate  at 
which  a  process  can  meet  customer 
demand).  Pull  triggering  systems  (also 
referred  to  by  the  Japanese  word: 
Kanban)  can  be  as  simple  as  min-max 
inventory  control  cards,  painted  floor 
squares,  and  Andon  (status)  lights,  or 
could  be  as  sophisticated  as  integrated 
process  flow  and  process  control 
software.  As  of  this  date,  we  are 
unaware  of  any  US  shipyard  applications 
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that  utilize  such  integrated  process 
control  software,  where  manufacturing 
operations  within  that  system  are  based 
on  the  “pull”  approach. 

Opportunities 

Opportunities  exist  to  provide  Lean 
practitioners  with  easier-to-use  process 
mapping  software,  capable  of  quickly 
generating  functional  (“swim-lane”) 
process  maps  with  composite  cycle  and 
touch  time  predictions/simulations. 
(Such  software  should  be  intuitive  to  use 
with  little  training.)  Data  mining 
applications  with  integrated  statistical 
analysis  tool  suites  and  decision  support 
systems  that  could  reach  across 
platforms  and  legacy  systems  would  be 
particularly  useful  in  providing  a  myriad 
of  insights  about  shipyard  operations  and 
improvement  opportunities.  ERP 
systems  which  could  feed  integrated 
process  control  software  for  local  pull 
triggering  with  visibility  at  a  program 
level  for  bottleneck  analysis  would  be 
particularly  helpful.  And,  perhaps  most 
importantly,  as,  what  is  measurable  gets 
measured^ what  gets  measured  gets 
managed^  what  gets  managed  gets 
done...  flexible,  activity-based  cost 
accounting  systems  with  objective 
schedule  progressing,  not  solely  based 
on  DoD-driven  cost  accounting  practices 
(i.e.,  independent  of  Earned  Value 
Management  Systems),  would  drive 
process  improvement  decisions  to 
“Investment  Thinking”  levels  on  and 
improvement-by-improvement  and 
enterprise-wide  basis. 


7.  Rapid  prototyping  (RP) 
technologies 

Background 

This  section  describes  rapid  prototyping 
technologies.  Rapid  prototyping  (RP)  is 
the  process  of  creating  a  physical,  solid 
(3D)  model  from  a  computer-based 
model  representation.  The  RP  model  is 
made  of  different  kinds  of  materials 
depending  on  the  particular  process  and 
technology.  In  fact,  material  type  is  the 
main  discriminator  for  the  limitations 
and  capabilities  of  the  different 
technologies.  RP  materials  include 
plastic,  wax,  laminates  and  metal.  Even 
though  it  is  a  physical  artifact,  the  output 
of  the  RP  process  is  still  a  model.  Its 
main  contribution  is  as  a  simulation,  not 
as  a  finished  work  product.  The  goal, 
then,  as  with  any  other  simulation,  is  to 
gain  some  benefit  from  the  model. 
Moreover,  it  must  be  possible  to  create 
an  RP  model  very  quickly  and  very 
inexpensively.  All  RP  technologies 
strive  for  this  goal;  each  one  is  generated 
directly  from  a  CAD  model  with  no 
intermediate  processes  required. 
Nevertheless,  some  of  the  technologies 
are  more  economical  than  others. 

RP  technology  is  actually  more  of  a 
publishing  technology  than  a  modeling 
technology.  The  assumption  is  that  the 
model  already  exists  in  digital  form.  The 
RP  model  is  one  particular  view  of  this 
model.  The  RP  view  is  based  solely  on 
the  geometry  of  the  CAD  model;  no 
design  features  are  passed  through.  The 
RP  model  is  based  on  a  facetted 
representation  of  the  CAD  model  rather 
than  an  ‘exact’  representation.  Such  a 
model  can  be  generated  from  virtually 
any  3D  CAD  platform.  The  data  is 
typically  transferred  to  the  RP  process 
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via  a  VRML  file  format  or  *.STL  file 
format.  As  a  publishing  technology,  RP 
can  be  evaluated  relative  to  other  styles 
of  publishing  -  from  2D  drawings  to  an 
actual  physical  mockup  to  an  individual 
CAD  session  to  a  visualization  (either  on 
a  terminal  or  to  a  printer)  to  a  virtual 
reality  session. 

Usage  scenarios 

The  challenge  is  to  find  a  usage  scenario 
in  which  the  RP  model  is  more  useful  or 
more  economical  than  the  competing 
styles  for  publishing  the  product  model. 
Unfortunately,  the  technology  is  not  well 
suited  to  shipyard  manufacturing  needs  - 
for  structures  or  for  piping.  Current 
modeling  capabilities  are  sufficient  to 
perform  static  interference  checking  on 
such  models.  RP  technology  is  not  well 
suited  for  interference  checking  of  space 
envelopes  because  the  RP  model  best 
corresponds  to  final  product 
configuration.  There  are,  however,  two 
usage  scenarios  where  the  RP 
technologies  show  promise:  conceptual 
design  modeling  and  dynamic 
interference  checking.  Even  the  early  RP 
technologies  are  well  suited  for 
conceptual  design  modeling.  In  this 
usage  scenario  a  CAD  system  is  used  to 
quickly  create  a  model  for  a  new  ship 
concept.  RP  technology  is  used  to 
generate  a  small-scale  model  that  can 
then  be  used  in  presentations  and 
discussions  about  the  new  concept. 

A  more  promising  usage  scenario  is 
dynamic  interference  checking.  The 
outfitting  and  assembly  phases  of  ship 
construction  entail  the  movement  of 
large  components  through  tight,  dense 
spaces.  A  digital  model  has  difficulty 
modeling  the  physics  of  this  situation. 
Even  static  interference  checking  is  very 


computationally  intensive;  dynamic 
interference  checking  of  a  component  as 
it  is  loaded  into  a  ship  is  even  more  so. 
Moreover,  the  modeling  of  such 
kinematics  is  time-consuming  and 
difficult.  However,  the  RP  model 
naturally  incorporates  the  physics  of 
interference  checking.  A  section  or 
compartment  of  the  ship  can  be 
published  as  an  RP  model  (at  any  stage 
of  completion).  The  component  to  be 
loaded  can  also  be  published  as  an  RP 
model.  Loading  paths  can  then  be 
simulated  by  using  the  RP  models. 
Interferences  become  readily  apparent  in 
such  a  simulation.  When  RP  technology 
is  cheap  enough  and  fast  enough  to 
publish  such  models  on  demand,  the  RP 
models  represent  valuable  tools  for 
effective  and  practicable  outfitting  plans. 

State  of  the  art 

Stereolithography 

Stereolithography  was  the  earliest  RP 
technology.  It  uses  lasers  to  harden 
liquid  polymer  material  into  solid  form  - 
driven  by  a  digital  CAD  model.  Because 
of  the  line  of  sight  limitations  of  the 
lasers,  there  are  some  limitations  on  the 
kinds  of  geometries  that  can  be 
supported.  Stereolithography  models  are 
very  accurate  and  durable;  however  they 
can  be  prohibitively  expensive  to 
produce.  Other  approaches  have 
followed,  trying  to  overcome  some  of 
the  cost  and/or  geometry  limitations. 
One  such  approach  is  laminated  object 
manufacturing,  which  builds  up  layers  of 
adhesive-coated  paper  to  make  a 
laminated  model.  Another  approach  is 
fused  deposition  modeling,  which  is 
based  upon  an  extrusion  approach. 
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3D  Printing  (3 DP) 

The  most  promising  new  approach  for 
the  shipbuilding  industry  is  3DP.  This 
approach  has  no  limitations  on  the 
geometries  supported  and  is  extremely 
fast  and  inexpensive.  In  this  approach  a 
powder-based  plaster  and  resin  material 
is  hardened  into  a  solid  shape.  Though 
the  quality  of  the  model  is  not  suitable 
for  a  finished  product,  the  accuracy  of 
this  approach  is  adequate  for  modeling 
purposes.  Most  important  the  hardware 
technology  for  this  approach  is  based  on 
commercial-off-the-shelf  components 
for  printers. 

Opportunities 

Dynamic  interference  checking 

The  3DP  approach  has  the  potential  to 
support  the  dynamic  interference  usage 
scenario  and  could  very  well  become  a 
valuable  tool  for  planning  of  ship 
outfitting  and  construction.  The 
technical  issues  that  need  to  be 
addressed  are  whether  the  technology 
could  support  models  of  the  complexity 
found  in  a  typical  ship’s  compartment. 
In  addition,  it  must  be  demonstrated  that 
such  models  can  be  generated 
substantially  cheaper  than  the  cost 
involved  in  creating  the  same  kinematic 
model. 

8.  Visualization 
Background 

Visualization  is  the  use  of  computer 
generated  3D  models  to  display  ship 
arrangements  or  detail  representations  of 
components.  The  3D  models  are 
typically  based  on  CAD  design  data  that 
has  been  electronically  translated  into  a 
format  suitable  for  viewing.  The  models 


can  be  viewed  on  a  desktop  computer, 
workstation  or  projected  on  a  large 
screen  for  full-scale  viewing  and  group 
collaboration.  Visualization  can  be  used 
throughout  the  design  and  construction 
phases  of  ship  production.  It  is  used  for 
rapid  evaluation  of  concepts  during  the 
early  stages  of  design  creation,  for 
design  review  during  detailed  design,  for 
assembly  planning,  and  for  pre-work 
familiarization  during  construction. 
Computer  generated  visualization  can 
serve  as  an  electronic  mockup,  allowing 
designs  to  be  seen,  analyzed,  and 
operated  without  the  need  for  scale 
models  or  test  platfonns. 

Visualization  is  being  used  in  the  U.S. 
shipbuilding  industry  on  all  major  naval 
design  efforts.  The  use  of  visualization 
in  commercial  shipbuilding  and  on 
smaller  design  projects  is  less 
widespread.  A  variety  of  software  tools 
are  available  to  support  this  work,  both 
special  purpose  computer  graphics  tools 
and  integrated  graphics  modules  in  naval 
architecture  and  CAD  packages. 
Visualization  is  being  used  primarily  as 
a  design  review  tool,  allowing 
arrangement  walkthroughs  and 
interference  checking,  at  all  phases  of 
the  design  process.  Visualization  is  also 
being  used  as  a  planning  and  validation 
tool  for  construction  assembly  and 
facility  use  planning.  It  is  also  used  in 
specialized  applications  such  as 
ergonomics  and  evaluations  of  human 
factors  and  display  of  maintenance  and 
repair  scenarios. 

State  of  the  Art 

The  high  end  of  visualization 
capabilities  in  the  shipbuilding  industry 
is  equal  to  the  state  of  the  art  in  other 
industries.  The  systems  in  place  to 
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handle  visual  review  of  design  data  for 
the  Virginia  submarine  program,  CVNX 
carrier  program,  and  LPD17  support 
ships  are  at  least  as  sophisticated  as 
those  used  in  the  aircraft,  automotive,  or 
AEC  industries.  These  large  ship  design 
projects  manage  greater  amounts  of 
graphical  data  than  all  but  the  largest 
plant  construction  projects.  Specialized 
graphics  computer  hardware  is  required 
for  very  large  models,  but  the  recent 
advances  in  commodity  PC  hardware 
have  made  reasonable  visualization 
capabilities  available  on  most  desktop 
computers.  Dedicated  software 

packages  are  available  for  capturing 
electronic  motion  pictures  and 
publication  quality  images  when  this  is 
required. 

Visualization  tools  can  be  separated  into 
two  categories  based  on  their  integrated 
usage  with  the  underlying  CAD  system. 
In  one  class  there  are  visualization  tools 
that  act  as  direct  extensions  to  the  CAD 
program,  as  though  they  were  another 
module  of  the  same  software  used  for 
design  creation.  At  the  most  basic  level 
nearly  all  CAD  programs  in  use  today 
have  some  capability  for  model 
visualization  built  in.  Programs  that 
model  objects  as  3D  solids  can  be  set  to 
display  the  current  scene  with  the  visible 
surfaces  shaded  and  hidden  lines 
removed,  to  provide  a  reasonably 
realistic  view.  A  more  sophisticated 
approach  in  these  integrated  tools  is  to 
launch  a  separate  rendering  or  viewing 
program  from  the  CAD  environment. 
The  current  geometry  model  is  translated 
from  its  CAD  representation  to  a 
lightweight  format  suitable  for  rapid 
display  and  transferred  to  a  separate 
viewer.  Examples  of  this  CAD/Viewer 
integration  would  be  the  connection  of 
CATIA  V4  and  4D  Navigator,  or 


CATIA  V5  and  DMU  Navigator,  from 
Dassault  Systemes.  This  integrated 
approach  has  the  benefit  of  maintaining 
a  single  (CAD)  data  store  for  both 
design  and  visualization  functions. 
Integrated  viewer  can  be  slow  for  very 
large  models  because  the  detailed 
product  model  data  must  first  be 
retrieved  in  the  CAD  system  and  then 
translated  for  viewing. 

The  second  category  of  visualization 
tools  are  those  that  work  as  standalone 
programs,  independent  of  the  CAD 
system.  To  support  independent  use 
these  viewing  tools  must  maintain 
separate  data  stores.  This  requires  the 
use  of  data  translation  programs  to  move 
files  between  the  CAD  and  visualization 
realms,  and  carries  the  added  burden  of 
data  management  for  these  separate  files. 
The  benefit  gained  by  maintaining  a 
dedicated  store  of  visualization  data  is 
speed  in  retrieving  large  amount  of  data. 
For  very  large  scale  visualization  this 
optimized  perfonnance  becomes  an 
overriding  concern,  and  model  retrieval 
time  is  a  limiting  factor.  The  three 
major  commercial  software  products 
used  for  industrial  visualization  tasks  are 
dvMockup  from  Division/PTC,  Envision 
from  Delrnia,  and  VisVicw/VisFly  from 
Engineering  Animation  Incorporated 
(EAI). 

Northrop  Grumman  Newport  News 
(NGNN)  has  a  long  history  of  3D  model 
visualization  for  ship  design,  beginning 
with  the  VIVID  program.  The  current 
design  work  at  NGNN  on  the  next 
generation  aircraft  carrier,  CVX,  makes 
extensive  use  of  two  different 
visualization  tools,  4D  Navigator  and 
dvMockup.  The  4D  Navigator  viewer  is 
integrated  with  the  CATIA  CAD 
environment.  It  is  used  for  small  to 
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medium  scale  design  review,  running  on 
the  same  engineering  workstations  used 
for  CAD.  DvMockup  is  used  for  large- 
scale  design  reviews  and  runs  on 
specialized  graphics  workstations  and 
graphics  supercomputers.  Visualization 
with  dvMockup  relies  on  a  dedicated 
model  store  that  is  translated  from  CAD 
into  a  special  format  for  viewing. 
Functional  modules  within  dvMockup 
enable  interactive  and  scripted 
walkthroughs,  collision  and  clearance 
detection,  evaluation  of  kinematic 
mechanisms  and  part  motion,  and 
ergonomic  analysis. 

The  Virginia  submarine  program  at 
General  Dynamics/Electric  Boat  (EB) 
has  made  extensive  use  of  the  IGRIP  and 
Envision  tools  from  Delrnia  (formerly 
Deneb  Robotics).  The  Envision  tool  is 
also  used  as  the  primary  visualization 
tool  on  the  LP17  program  at  Northrop 
Grumman  Avondale.  The  use  of 
Envision  in  these  two  design  programs 
relies  on  dedicated  data  stores  translated 
from  the  CAD  source.  Visualization  is 
done  on  large  scale  sections  of  the  ship 
arrangement  using  dedicated  graphics 
workstations  and  supercomputers.  The 
functionality  available  includes 
walkthroughs,  collision  detection,  part 
motion  and  kinematics,  ergonomic 
studies,  and  integration  with  time- 
dependent  simulations.  Visualization  is 
used  for  design  review  and  verification 
of  assembly  planning  and  construction 
sequences. 

Opportunities 

Data  management  and  integration  with 
design  PDM 

Large  scale  visualization  systems 
typically  make  use  of  dedicated  data 


stores  that  are  independent  of  the  CAD 
source  models.  Managing  this  data  and 
maintaining  consistency  with  the  CAD 
product  model  data  is  a  difficult  task. 
Each  visualization  tool  assumes  a 
different  data  storage  architecture, 
optimized  for  logical  file  maintenance 
and  model  retrieval  performance. 
Ideally  the  visualization  data  could  be 
managed  in  a  PDM  system  similar  to 
that  used  for  CAD  data  management. 
This  would  require  integration  between 
the  visualization  and  PDM  software,  and 
tuning  of  the  PDM  system  to  enable  the 
highest  perfonnance  in  retrieval  of  large 
numbers  of  model  files.  Another  area  of 
integration  between  visualization  and 
PDM  systems  would  be  the  ability  to 
dynamically  query  back  and  forth 
between  the  viewing  and  data  realms. 
The  graphical  display  could  enable  a 
query  from  a  particular  object  (“click 
and  discover”)  to  retrieve  non-graphical 
part  data  such  as  system  designator, 
material  properties,  or  vendor 
information.  As  a  corollary,  the  PDM 
interface  could  allow  standard  SQL 
queries  based  on  system,  ship  location, 
or  part  name  to  retrieve  a  desired 
arrangement  view. 

Integration  with  MRP  and  construction 
data 

Most  visualization  systems  in  use  in  the 
shipbuilding  industry  are  based  on  CAD 
design  models  and  are  organized 
according  to  the  design  product  structure 
and  design  bill  of  materials.  As  design 
parts  are  rolled  up  into  assemblies  and 
build  units  during  the  planning  process 
and  organized  into  a  construction  bill  of 
material  the  associativity  between  the 
original  CAD  parts  and  shipyard 
consumable  parts  listed  in  MRP  can  be 
lost.  In  naval  shipbuilding,  where  each 
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hull  carries  unique  design  changes  that 
must  be  traceable,  there  is  the  further 
difficulty  of  maintaining  a  list  of  hull- 
applicable  piece  parts.  Visualization 
systems  have,  in  their  short  history,  been 
focused  on  design  data.  Changes  need  to 
be  made  to  accommodate  multiple 
product  structures  and  bill  of  materials. 
MRP  systems  may  also  need  to  be 
enhanced  in  order  to  carry  associativity 
at  the  piece  part  level  from  construction 
parts  back  to  source  CAD  data. 

Visualization  on  the  shop  floor 

The  shop  floor  and  shipyard 
environments  have  typically  enjoyed 
limited  support  for  advances  in  computer 
hardware  and  information  services.  The 
past  decade  has  seen  a  revolution  in 
information  processing  on  the  design 
floor,  both  in  computer  hardware  and 
software.  Similar  advances  have  not 
been  carried  through  to  the  operations 
facilities.  The  use  of  visualization 
software  with  improved  computer 
hardware  in  manufacturing  areas  has 
many  useful  applications.  Display  of 
assembly  sequences  can  be  used  for 
verification  of  construction  planning  and 
for  pre-start  familiarization  by  work 
crews.  Visualization  linked  to 
underlying  MRP  and  PDM  data  can  be 
used  as  a  means  of  performing  queries 
for  necessary  manufacturing 
information.  Ultimately  the  3D  model 
displayed  on  a  computer  could  be  used 
as  the  paperless  shop  to  eliminate  the 
need  for  printed  drawings. 

Distributed  desktop  visualization 

The  visualization  systems  in  use  today 
for  ship  design  make  use  of  dedicated 
computer  hardware  that  is  exclusively 
tied  to  either  the  CAD  system  or  the 


visualization  system.  These  are  special 
purpose  computers  that  are  used  only  for 
design  creation  and  design  review. 
Historically  these  dedicated  computers 
were  required  in  order  to  provide  the 
necessary  processing  power  to  render 
large  arrangement  models  in  3D.  Today 
standard  desktop  PCs  are  adequate  to 
handle  visualization  of  reasonably 
complex  arrangements.  However,  the 
standard  PCs  in  use  throughout  the  ship 
design  organization  often  do  not  have 
network  access  to  the  visualization  data 
and  do  not  have  viewer  software.  The 
monolithic  visualization  systems  that 
were  based  on  dedicated  hardware  need 
to  be  adapted  to  a  lightweight  distributed 
environment.  Modifications  may  need 
to  be  made  to  enable  viewing  of  smaller 
area  breakdowns  to  account  for  less 
capable  hardware.  Ease  of  use  and  ease 
of  data  access  will  also  need  to  be 
addressed  as  the  user  base  changes  from 
dedicated  expert  users  to  more  novice 
and  casual  users.  The  overall  review 
process  may  also  need  to  be  changed  to 
take  advantage  of  the  widespread, 
immediate  access  to  the  ship  design  data. 

III.  Integration  Strategies  and 
Technologies 

1.  Systems  technology  requirements  in 
the  shipbuilding  industry 

Regardless  of  the  size  of  the  ship,  the 
shipbuilding  product  life  cycle  typically 
takes  the  form  illustrated  in  Figure  3. 
There  are  four  major  stages  in  the  life 
cycle.  For  simplicity,  Figure  3  represents 
a  waterfall  process,  but  in  reality  the 
shipbuilding  process  is  iterative  at 
virtually  every  stage.  Nevertheless,  the 
waterfall  model  does  shed  some  light  on 
the  relationship  between  adjoining 
process  steps.  Typically,  each  major 
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process  step  results  in  a  handoff  to  the 
next  step.  The  handoff  is  comprised  of 
the  information  deliverables,  the  product 
model  work  products,  that  are  used  as 
the  basis  of  the  next  process  step.  The 
subsequent  process  step  refines  the 
product  model.  The  new  model  adds 
new  information  and  new  value.  The 
block  arrows  in  Figure  3  represent  the 
handoffs.  Despite  the  separation,  no 
process  step  is  independent  of  its 
predecessor. 


tools  to  support  each  process  and  2)  to 
support  the  interactions  between 
processes.  Each  major  process  is 
supported  by  one  or  more  application 
systems.  None  of  these  systems  is  simple 
to  deploy;  each  embodies  its  own  unique 
set  of  technical  challenges.  However,  the 
real  payback  from  these  systems  is  not 
realized  until  they  are  integrated  into  a 
larger  “product  development 
environment.”  There  are  two  approaches 
available.  One  approach  is  to  deploy  an 
IDE  is  illustrated  in  Figure  4: 


IDEA! 


Figure  3:  Shipbuilding  Product  Life 
Cycle 

Each  stage  in  the  product  life  cycle  is 
comprised  of  a  number  of  smaller 
processes.  The  pattern  of  hand-offs  and 
dependencies  is  repeated  even  at  the  sub¬ 
process  level.  This  pattern  applies  at  all 
levels  and  within  all  stages  of  the 
product  life  cycle,  and  it  provides  an 
insight  into  the  shipbuilding  systems 
technology  requirements.  The 
shipbuilding  product  life  cycle  is  a 
complex  process  flow  in  which  each 
activity  iteratively  feeds  a  refined 
product  model  as  the  primary  work 
product  to  the  next  activity,  and  that 
activity  must  maintain  visibility  into  its 
predecessor’s  data. 


SHIP! 

Figure  4:  Integrated  Development 
Environment 

The  goal  of  the  IDE  is  to  integrate  the 
systems  within  a  given  shipyard  as 
tightly  as  possible  in  order  to  automate 
the  inter-process  hand-off  and  support 
interactions.  There  is  a  single  process 
flow.  One  concept  initiates  the  process 
and  defines  a  class  of  ship,  and  the 
objective  is  produce  and  support  one  or 
more  ships  of  that  class.  The 
requirement  is  that  each  inter-process 
interaction  be  as  seamless  as  possible. 
Today  the  first  tier  US  shipyards  are  still 
striving  to  deploy  IDEs  to  accomplish 
this  goal. 


The  shipbuilding  industry  relies  on 
systems  technology  to  satisfy  two 
different  requirements:  1)  to  provide  the 


At  the  same  time  new  business 
requirements  have  emerged,  and  the 
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trend  has  been  toward  collaboration 
among  shipbuilders  and  their  industry 
and  government  partners.  Among  Navy 
programs,  major  programs  are 
increasingly  being  awarded  to  alliances. 
Collaboration  is  encouraged,  and  in 
some  cases  unavoidable,  between 
shipbuilders,  systems  integrators, 
suppliers,  design  agents,  construction 
yards,  and  support  organizations. 
Collaboration  is  also  emerging  as  a 
business  requirement  among  commercial 
shipbuilders.  When  collaboration 
becomes  a  system  requirement,  the  face 
of  the  development  environment  changes 
drastically.  Figure  5  illustrates  an 
Interoperable  Collaborative 

Development  Environment  (ICDE): 


Figure  5:  Interoperable  Collaborative 
Development  Environment 

The  ICDE  differs  from  the  IDE  in  that 
the  inter-process  handoffs  may  now 
cross  enterprise  boundaries  as  well  as 
system  boundaries.  The  ICDE  must  be 
designed  to  accept  a  handoff  from  some 
other  ICDE  at  any  point  in  the  product 
life  cycle.  For  example,  two  companies 
may  share  the  design  of  the  major 
components  of  the  propulsion  system  of 
one  class,  or  one  shipyard  may  be  the 
construction  yard  for  a  ship  that  was 


designed  elsewhere.  This  requirement 
puts  new  constraints  on  the  technology 
associated  with  each  hand-off. 
Seamlessness  is  no  longer  the  overriding 
goal  to  be  attained  at  all  costs.  Now  the 
goal  is  openness.  The  ICDE  must 
minimize  the  burden  on  its  downstream 
team  members.  Moreover,  recent 
advances  in  information  technology  have 
made  it  feasible  to  use  this  approach  for 
tool  integration  within  a  single  shipyard 
as  well. 

2.  Matching  technologies  to 

requirements 

Today  there  are  two  leading  families  of 
systems  technologies:  component 

software  for  distributed  objects  and 
information  interoperability. 

Shipbuilders  are  very  familiar  with  the 
concept  of  components;  a  ship  is 
essentially  a  composition  of 

components,  and  the  more  standard 
components  can  be  used,  the  more  cost- 
effective  the  ship.  In  fact,  standard 
components  are  well  established  and 
well  understood  in  most  engineering 
disciplines.  However,  until  recently 
components  have  been  unsuccessful  in 
the  world  of  software  systems.  A 
software  component  is  a  piece  of 
software  that  is  independently  produced, 
acquired  and  deployed.  It  interacts  with 
other  software  components  to  fonn  a 
functioning  system.  Composite  systems 
composed  of  standard,  re-usable 
software  components  are  called 
component  software.  Component 
software  is  a  key  enabler  for  system 
building.  This  technology  represents  the 
first  alternative  for  systems  integration. 

Component  software  is  closely  allied 
with  distributed  object  technology. 
Today  there  are  three  major  competitors 
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in  this  space:  Microsoft’s  DCOM, 
CORBA  C++  and  Enterprise  JavaBeans. 
This  technology  is  high-tech  with  a  high 
cost  of  entry;  it  is  a  technology  “for  the 
elite”.  In  its  enterprise  form  it  can  be 
afforded  and  supported  only  by  large 
enterprises.  It  is  behavior-centric.  Its 
primary  purpose  is  the  building  of 
systems,  that  is,  the  implementation  of 
tools  that  can  create,  manage  and  modify 
the  work  products  of  an  enterprise.  It  is 
highly  dependent  upon  a  particular 
technology  infrastructure. 

The  current  direction  in  the  U.S. 
shipbuilding  industry  is  leaning  heavily 
toward  a  dependence  upon  component 
software  and  the  system  vendors  that 
have  adopted  it.  This  approach  makes 
sense  with  respect  to  the  system  building 
requirement.  However,  it  is  seriously 
flawed  as  a  solution  to  the  systems 
integration  requirements  of  the  industry. 

At  the  other  end  of  the  systems 
technology  spectrum  is  information 
interoperability.  Information 

interoperability  is  the  ability  for  all 
stakeholders  to  link  to  and  access 
information  dependent  of  the  platform  or 
technology  that  owns  and  manages  the 
information.  Information  interoperability 
is  the  interchange  of  information  across 
information  boundaries,  including 
technology,  organizational,  system  and 
computer  process  boundaries.  It  involves 
the  pervasive  use  of  standards. 
Information  interoperability  and 
component  software  can  work  together, 
but  as  we  will  see,  they  represent 
essentially  different  technologies. 
Infonnation  interoperability  is  a  key 
enabler  for  the  integration  of  systems 
into  a  product  development 
environment. 


Without  going  too  deep  into  the  details, 
each  technology  has  certain 
characteristics  that  must  be  considered  in 
order  to  apply  the  technology  to 
requirements  profitably.  Information 
interoperability  is  centered  in  the 
Internet  world.  Its  standards  are 
developed  and  adopted  by  the  World 
Wide  Web  Consortium  (W3C),  and  its 
base  is  the  XML  family  of  technologies. 
The  technology  is  low-tech  with  a  low 
price  of  entry.  It  is  a  technology  “for  the 
masses”;  vendors  target  a  high-volume, 
low  cost  market.  It  is  information¬ 
centric.  The  metaphor  in  the  XML  world 
is  the  document.  This  technology  seeks 
to  make  infonnation  availability  its  top 
priority.  Simplicity  is  central  to  its 
philosophy.  Lor  example,  XML  became 
successful  by  restructuring  an  existing 
technology  and  providing  80%  of  the 
functionality  with  20%  of  the 
complexity.  XML  is  designed  for 
technology  independence.  The  rule  of 
the  Internet  is  that  one  can  never  be  sure 
what  kind  of  computer  or  system  is  on 
the  other  end  of  the  network. 

3.  Enterprise  Application  Integration 
with  XML  and  Web  Services 

Live  years  ago,  the  only  technology 
options  available  for  enterprise 
application  integration  were  the 
component  software/distributed  object 
technologies.  These  technologies  had  the 
drawback  that  they  were  complex  and 
carried  considerable  overhead.  As  a 
result,  they  were  only  available  to 
enterprises  that  had  substantial 
information  technology  resources.  Each 
distributed  object  technology  required  its 
own  team  of  experts  making  integration 
across  technology  frameworks  very 
difficult.  Since  that  time,  Web 
technologies  have  matured  to  the  point 
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that  most  shipyards  support  an  Intranet 
infrastructure  and  know  how  to  deal  with 
and  maintain  Web  servers  and  associated 
support  tools.  Moreover,  the  standards 
for  data  sharing  using  XML  have 
advanced  to  the  point  that  tools  are  now 
widely  available  to  process  and 
manipulate  the  XML  data  that  would  be 
the  core  of  such  a  systems  integration 
infrastructure.  Early  efforts  at  building 
CIM  (computer  integrated 

manufacturing)  frameworks  were 
frustrated  precisely  by  a  lack  of  such  an 
infrastructure.  The  first  proponents  of 
this  approach  found  that  they  had  to 
devote  most  of  their  resources  to  putting 
the  underlying  enablers  in  place.  These 
enablers  included  such  basics  as 
security,  access  control,  data  translators, 
directories,  query  and  search  engines, 
presentation  services,  and  inter-system 
messaging.  With  this  approach,  the 
entire  integration  problem  became 
bogged  down  in  software  development 
issues.  Nothing  could  be  accomplished 
with  software  programmers,  and  when  a 
system  was  in  place  it  was  limited  in 
extensibility  and  re -usability.  The 
landscape  has  changed  with  the  advent 
of  Web  and  Web  services  technologies. 
Now  much  of  the  infrastructure  is 
already  to  the  shipyard  via  its  Intranet 
foundation.  Database  vendors  are 
providing  tools  to  make  XML  data 
directly  available  through  the  Web 
servers.  Tools  are  in  place  so  that 
information  interoperability  can  be 
accomplished  largely  by  means  of 
configuration  files  -  many  of  which  can 
be  created  and  maintained  by  shipyard 
personnel  themselves. 

The  issue  of  system  integration  is 
especially  important  for  the  support  of 
production  processes.  Apart  from  their 
own  interactions,  production  processes 


rely  heavily  on  infonnation  that  is 
created  and  managed  within  the  ship 
design  systems.  This  information 
includes  the  complex  product  model  data 
that  ultimately  must  be  translated  into 
instructions  that  can  be  understood  by  a 
tradesman  or  into  CNC  code  that  can 
drive  the  manufacturing  process.  The 
single,  monolithic  system  approach  has 
become  an  inhibitor  to  progress  within 
production  processes.  This  approach  is 
still  being  advanced  by  major  ERP 
systems  vendors  such  as  SAP  and  by  the 
major  CAD/PDM  vendors.  However,  the 
shipbuilding  industry  should  begin  to 
assert  its  prerogative  for  more  modular 
systems  supports.  The  software  industry 
is  moving  rapidly  to  embrace  the  Web 
services  architecture.  In  this  architecture, 
software  services  are  presented  in 
modular  and  interoperable  fonn  that  can 
be  composed  to  accomplish  more 
complex  ends.  Moreover,  the  system 
infrastructure  that  supports  the 

integration  is  built  upon  Web  and 
Intranet  technologies  that  are  already 
widely  supported  within  the  shipyards 
and  which  are  simple  and  economical 
enough  that  they  can  be  used  by  small 
and  medium-sized  enterprises  as  well. 
By  adopting  this  approach,  the 

shipbuilding  industry  also  needs  to  re¬ 
examine  the  role  of  software 
outsourcing.  There  should  be  an  effort  to 
restrict  outsourced  software  services  to 
infrastructure  support  and  to  minimize 
(or  eliminate)  the  need  for  application 
development.  The  Web  services 

architectures,  especially  the  use  of  XML 

for  information  sharing,  enables  the  use 
of  configuration  files  and  scripts  to  fine- 
tune  and  customize  systems  and  system 
integrations.  The  shipbuilding  industry 
should  begin  to  position  itself  so  that  its 
own  personnel  can  accomplish  these 
customizations.  This  represents  a  change 
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not  just  in  technology,  but  also  in  the 
culture. 

4.  Strategy  for  information 
interoperability 

Systems  integration  by  means  of 
information  interoperability  is  the  key 
enabler  for  potential  savings  among 
shipbuilding  production  processes.  The 
information  requirements  for  the 
shipbuilding  production  processes  are 
quite  similar  for  all  shipyards,  defense  as 
well  as  commercial.  Moreover,  co¬ 
production  between  shipyards  presents  a 
key  opportunity  to  maximize 
productivity.  In  some  programs  the 
sharing  of  work  is  contractually 
required;  in  other  programs,  such  a 
sharing  of  work  is  the  best  means  to 
improve  efficiencies  in  cost  and 
schedule.  Co-production  makes  it 
possible  for  a  program  to  best  exploit  the 
core  competencies  and  other  advantages 
of  different  shipyards.  Co-production 
provides  the  opportunity  for  defense 
yards  to  more  cost-effectively  support 
customer  requirements.  It  also  provides 
the  opportunity  for  commercial  yards  to 
share  in  some  aspects  of  defense 
shipbuilding. 

Current  initiatives  such  as  the  NSRP 
systems  technologies  projects  (ISE, 
SPARS,  ISPE),  the  DoN  XML 
repository  and  the  Navy  ERP  initiatives 
are  addressing  the  problem  by  defining 
information  standards  and  infrastructures 
for  the  sharing  of  shipbuilding  data. 
Unfortunately,  there  is  a  non-technical 
obstacle  to  the  full  implementation  of 
this  information  sharing  approach.  In 
many  cases  the  information  is  more 
valuable  to  the  receiving  yard  than  to  the 
sending  yard.  The  sending  yard  of  the 
information  is  typically  under  contract  to 


provide  the  information,  but  in  most 
cases  it  does  so  in  the  easiest  way 
possible.  There  is  no  cost  incentive  for 
the  sending  yard  to  devote  its  own 
resources  to  make  the  infonnation  easier 
to  use  by  the  receiving  yard.  In  the 
design  arena,  a  similar  calculation 
applies  to  the  CAD/PDM  vendors.  Most 
CAD/PDM  vendors  are  eager  to  import 
data  from  other  systems  into  their  own 
environment,  but  they  are  less 
enthusiastic  about  making  their  own  data 
available  for  use  in  competitors’ 
systems. 

The  architecture  for  infonnation 
interoperability  among  shipbuilding 
systems  should  utilize  the  concept  of 
data  mediation  and  should  be 
constructed  around  a  global  data  broker 
capability.  The  global  data  broker  is  a 
central  medium  to  leverage  software 
applications  and  data  to  accommodate 
the  myriad  of  databases  and  data 
processing  methodologies  being 
managed  by  various  communities’ 
shipbuilding  production  processes.  The 
challenges,  both  technical  and  cultural, 
are  similar  to  those  encountered  in  recent 
attempts  at  enterprise  application 
integration  (EAI).  While  enterprise 
application  integration  presents  obstacles 
that  have  still  not  yet  been  fully 
overcome,  global  information 
interoperability  represents  even  greater 
challenges.  It  is  helpful  to  consider 
global  information  interoperability  in 
light  of  the  lessons  learned  in  enterprise 
integration.  Each  process  stage  has  its 
own  mission  to  accomplish.  Access  to  a 
store  of  information  is  typically  an 
essential  part  in  accomplishing  this 
mission.  Each  process  stage  deals  with 
two  kinds  of  information  -  the 
information  that  it  creates  and  manages 
for  its  own  ends  and  the  information  that 
it  receives  from  other  processes. 
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Some  of  the  information  created  by  the 
process  team  is  private  and  of  no  use 
outside  the  team,  but  some  of  the 
information  supports  the  missions  of 
other  teams  and  must  be  made  available 
to  those  authorized  to  use  it.  Within  the 
typical  enterprise  today,  the  information 
systems  of  each  organization  consist  of  a 
diversity  of  computer  platforms, 
middleware  technologies  and  database 
management  systems.  Each  organization 
devotes  most  of  its  wherewithal  to  the 
accomplishment  of  its  own  mission.  Its 
private  information  is,  thus,  optimized  to 
capture  the  information  requirements 
appropriate  to  that  mission.  In  the  global 
arena,  this  situation  is  exacerbated.  It  is 
unrealistic  to  expect  that  a  team  will 
sacrifice  its  own  mission  to  support  the 
needs  of  global  interoperability,  which 
by  their  very  nature  are  constantly 
evolving  and  can  never  be  fully  known 
in  advance.  Even  in  today’s  enterprises 
most  information  exchange  occurs  by 
means  of  hard-coded,  point-to-point 
solutions,  each  highly  dependent  on  the 
technology  used  for  the  integration  (and 
sometimes  on  the  technology  used  in  the 
legacy  systems  themselves).  The  end 
result  is  a  rigid  infrastructure,  which  can 
be  extended  only  at  great  (and  often 
prohibitive)  cost. 

A  salient  lesson  from  current  EAI 
endeavors  deals  with  the  support  of  the 
system  after  deployment.  A  system  that 
is  tightly  coupled  to  particular 
technologies  can  become  too  brittle  to  be 
maintained  in  the  face  of  the  change  that 
is  inevitable.  This  is  a  valuable  lesson 
for  the  architecting  of  the  global  data 
broker;  however,  before  it  gets  to  that 
point  the  global  data  broker  must  first 
solve  the  problems  associated  with 
widespread  deployment.  Major 
enterprises  have  enough  central  authority 
to  deploy  a  manageable  subset  of 


enabling  technologies.  There  is  no  such 
central  authority  for  the  global  data 
broker,  which  can  be  realized  only  after 
a  sufficient  set  of  enabling  technologies 
have  achieved  world-wide  adoption. 

The  functional  requirements  for  the 
global  data  broker  are  roughly 
equivalent  to  the  functional  requirements 
associated  with  enterprise  integration; 
however,  the  non-functional 
requirements  are  significantly  different, 
and  the  result  is  that  current  EAI 
technologies  are  not  completely 
satisfactory  for  the  global  data  broker. 
Some  of  the  key  non-functional 
requirements  of  the  global  data  broker 
are  that  it  must: 

-  maximize  the  autonomy  of  the 
participating  teams 

-  be  built  on  widely-adopted,  open 
standards 

-  be  maintainable  in  the  face  of  change 
and  incomplete  requirements 

-  assure  the  protection  of  the 
infonnation  and  information 
infrastructure  of  the  participating 
teams 

-  be  modular  in  design 

The  cost  of  entry  for  a  participating  team 
must  be  low  enough  that  accommodating 
the  needs  of  the  global  user  community 
does  not  jeopardize  the  ability  to  meet  its 
own  private  needs.  The  cost  of 
participation  must  be  substantially 
smaller  than  the  benefit  from 
participation  (because  the  benefits  are 
often  seen  as  intangibles  without 
quantification).  In  practical  terms,  this 
means  that  the  global  data  broker  must 
make  it  as  easy  as  possible  for  a  team  to 
join  and  to  participate.  This  means  that 
the  global  data  broker  must,  on  the  one 
hand,  accommodate  the  semantic 
differences  between  different  teams’ 


63 


systems;  and,  on  the  other  hand,  it  must 
hide  all  syntactic  differences.  The  global 
data  broker  must  be  capable  of  hiding 
implementation  differences  at  every 
level  -  from  the  information  syntax  to 
the  underlying  data  model  to  the  query 
language.  In  other  words,  the  global  data 
broker  must  be  free  from  any  tight 
coupling  to  or  reliance  on  any  particular 
implementation  technology. 

It  is  important  to  resist  the  temptation  to 
adopt  critical  enabling  technologies  that 
are  proprietary  or  closed.  This 
temptation  is  especially  strong  if  a 
proprietary  technology  offers  some 
unique  discriminators  or,  worse,  if  the 
alternative  is  no  implementation  at  all.  In 
fact,  the  global  data  broker  should  not  be 
deployed  until  the  complete  set  of 
enabling  technologies  has  been  widely 
adopted  as  open  standards,  with  multiple 
vendor  support.  This  is  the  unique 
opportunity  for  the  global  data  broker. 
The  recent  emergence  of  the  family  of 
Web  and  XML  standards  marks  the  first 
time  this  requirement  has  been  satisfied. 

The  global  data  broker  must  be 
maintainable.  It  must  be  relatively  easy 
to  extend  the  infrastructure  to  adopt  to 
change  instigated  by  new  functional 
requirements,  new  supporting 
technologies,  new  platforms,  new 
combinations  of  participating 
communities 

Background:  fusion  or  mediation  -  The 
need  for  infonnation  interoperability  has 
long  been  recognized.  Since  the  early 
1990s  there  have  been  two  predominant 
architectural  approaches:  fusion  and 
mediation.  Most  early  EAI  strategies 
focused  on  the  fusion  approach:  the 
definition  of  a  single  organization-wide 
schema.  Early  implementations  of  the 
approach  typically  took  the  fonn  of  a 


single  database  management  system  that 
was  accessible  to  all  users  within  the 
organization.  Driven  by  the  need  for  data 
access  with  the  organization,  these 
efforts  did  not  address  the  needs  of  users 
in  other  organizations.  The  technology 
supported  the  closed  approach,  and  it 
was  possible  to  accomplish  the  job  at 
hand.  No  technology  existed  for  a  more 
open  solution,  and  the  price  of 
integration  was  too  high. 

Eventually  the  need  for  enterprise-wide 
integration  became  apparent  -  usually 
after  a  number  of  organization-wide 
systems  were  in  place.  The  first  thought 
in  many  IT  organizations  was  to  expand 
the  fusion  approach  to  the  enterprise 
level.  This  demanded  the  definition  of  a 
single  global  schema  for  the  enterprise, 
which  was  often  attempted  by  the 
implementation  of  single  database 
management  system.  The  thought  was 
that  the  same  approach  that  worked 
within  an  organization  would  work 
across  organizations.  Moreover,  there 
were  still  no  other  viable  alternatives. 

Yet  there  were  serious  issues  with  the 
fusion  approach  as  an  enterprise 
integration  tool.  It  necessitated  the 
replacement  of  local  databases  as  well  as 
the  migration  of  existing  applications  to 
the  new  database.  Some  enterprises  were 
willing  to  make  this  leap  and  they  found 
new  problems.  The  migration  of  legacy 
systems  is  a  costly  process,  demanding 
the  expertise  of  professional 
programmers  and  database  engineers. 
The  most  daunting  problems,  however, 
had  to  do  with  managing  change,  given 
the  resistance  of  the  fusion  approach  to 
change.  In  most  large  enterprises  process 
re-engineering  is  continuous. 
Application  requirements  often  change 
independently  of  integration 
requirements.  Moreover,  with  the  tight 
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coupling  of  the  first  deployments  every 
change  in  technology  or  implementation 
upgrade  precipitates  changes  in  the 
deployment.  The  tight  coupling  of  every 
application  to  the  enterprise  schema 
makes  local  change  painful  and 
disruptive.  What’s  worse,  many 
enterprises  had  already  adopted  a  COTS 
strategy  with  respect  to  software,  and 
they  lacked  the  ability  to  modify  these 
applications. 

The  single  system  (data  warehouse) 
variant  of  the  fusion  approach  reaches  its 
limit  in  enterprise-wide  integration.  For 
the  challenge  of  inter-enterprise 
integration,  the  technical  barriers  are 
insurmountable.  The  technology  itself 
breaks  down  -  it  is  not  possible  to 
deploy  a  single  DBMS  or  even  a  single 
middleware  technology  across  system 
domains  such  as  those  imposed  by 
enterprise  firewalls.  Moreover, 
participation  in  an  inter-enterprise 
integration  demands  a  degree  of  local 
autonomy  not  realizable  with  the  fusion 
approach. 

An  alternative  architecture  for 
information  interoperability  is 
mediation.  The  idea  is  to  employ  the 
principle  of  federation.  The  autonomy  of 
local  systems  is  maximized,  although 
each  local  system  surrenders  a  small 
amount  of  autonomy  in  exchange  for  the 
benefits  of  integration.  The  goal  of  the 
architecture  is  to  make  the  couplings  in 
the  system  as  loose  as  possible,  that  is,  to 
remove  all  accidental  couplings  - 
platform,  programming  language, 
middleware  technology,  query  language, 
even  the  data  model  itself.  The  crux  of 
the  mediation  objective  is  to  deliver 
information  to  the  user  in  a  form  that  is 
usable  to  him  regardless  of  the  form  or 
location  in  which  it  is  stored. 
Consequently,  the  key  enablers  of  the 


mediation  approach  are  transformations, 
both  of  the  information  itself  and  of  the 
queries  that  guide  the  access  to  the 
information. 

Having  committed  to  maximizing  the 
autonomy  of  the  local  data  sources,  the 
burden  now  falls  on  the  technology  to 
solve  all  the  inhibitors  to  autonomy,  and 
there  are  many.  The  utilization  of 
mediation  to  achieve  information 
interoperability  demands  that  each 
technology  enabler  not  only  be 

efficacious  but  also  widely  accepted  and 
widely  adopted.  Early  implementations 
of  the  mediation  architecture  have 
proven  technically  feasible,  even 

successful;  however,  they  have  not  met 
with  widespread  adoption  because  they 
have  relied  on  enabling  technologies  that 
render  the  solution  as  closed  as  the 
fusion  approach.  A  mediation 

architecture  built  upon  the  ODMG 
standards  for  object  databases  and  object 
query  language  has  been  proved  to  work, 
but  its  potential  adoption  is  limited  to 
systems  that  embrace  that  technology. 
Until  recently  the  list  of  technology  gaps 
that  precluded  the  use  of  mediation  was 
quite  long: 

-  a  universal  syntax  for  the 
representation  of  information 

-  a  common  query  language 

-a  messaging  capability,  including  the 
means  to  deliver  messages  as  well  as 
an  open  fonnat  for  the  message 
payload 

-  a  technology  independent  means  for 
specifying  interfaces 

-  a  widely  implemented  information 
modeling  language 

The  lack  of  technology  support  in  any 
one  key  area  disqualifies  mediation  as  a 
serious  contender  as  a  solution  for  the 
global  data  broker.  Finally,  the 
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deployment  of  the  mediation  architecture 
in  relatively  closed  environments  has 
obscured  a  number  of  second-generation 
inhibitors.  For  example,  mediation  is 
often  presented  as  an  alternative  to  the 
fusion  approach  when,  in  fact,  mediation 
cannot  work  without  an  implicit  global 
schema  of  its  own.  The  global  schema 
used  for  mediation  is  subtly  different 
from  the  global  schema  used  for  fusion, 
but  many  of  the  technical  issues  that 
need  to  be  addressed  can  be  understood 
best  in  light  of  experience  with  fusion 
methodologies.  The  global  data  broker, 
then,  depends  upon  a  new  approach,  a 
synthesis  of  fusion  and  mediation 

IV.  Prioritized  Development  Roadmap 

This  section  summarizes  the 
opportunities  for  improving  production 
processes  by  means  of  new  systems 
technologies.  It  is  presented  in  the  form 
of  a  development  roadmap.  The  specific 
opportunities  are  described  in  detail  in 
the  sections  above.  In  this  section  the 
opportunities  are  presented  as  tasks  that 
are  grouped  into  related  categories.  The 
categories  are  prioritized.  The  three 
categories  are: 

Deployment  of  a  complete  product 
modeling  capability  -  It  has  been  the 
intention  within  the  shipbuilding 
industry  for  the  past  decade  to  exploit 
the  benefits  of  a  product  model.  There 
have  been  considerable  gains  in  a 
surprisingly  short  period  of  time; 
however,  there  is  no  capability  among 
US  shipbuilders  to  create,  manage  and 
share  a  complete  product  model.  There 
are  gaps  in  all  stages  of  the  shipbuilding 
life  cycle.  This  report  enumerates  only 
those  that  are  related  to  production 
processes  (directly  or  indirectly). 
Moreover,  there  are  some  areas  that  have 


only  begun  to  be  addressed.  In 
particular,  new  systems  technologies  in 
the  area  of  accuracy  control  have  been 
deployed  mainly  as  standalone 
capabilities.  The  full  benefits  of  these 
capabilities  will  only  be  realized  when 
the  requirements  that  they  generate  are 
added  to  existing  CAD  and  CAM 
capabilities. 

Adoption  of  modular,  interoperable 
systems  -  Because  the  shipbuilding 
functional  requirements  are  so 
demanding,  the  industry  has  always  been 
pushing  technology  providers  to  their 
limits.  Until  now  there  has  been  little 
opportunity  to  select  among  technology 
providers  on  other  than  functional 
criteria.  The  major  systems  technology 
investments  have  been  in  monolithic 
systems  that  maximized  available 
functionality.  With  today’s  technologies 
starting  to  change,  technology  offerings 
can  now  be  evaluated  on  the  additional, 
non-functional  criteria,  such  as 
modularity  and  interoperability.  Over  the 
past  decade  the  shipbuilding  industry  has 
had  the  opportunity  to  experience  the 
difficulties  associated  with  monolithic 
systems.  Although  it  may  be  possible  to 
deploy  such  a  system  and  satisfy  the 
specific  functional  requirements  of  a 
business  process,  it  has  proved  very 
difficult  to  integrate  these  systems  with 
other  systems  within  a  shipyard. 
Interoperability  across  organizations  is 
limited,  and  it  is  very  difficult  to 
modernize  such  systems.  The  result  is 
that  many  shipyards  are  forced  to 
maintain  functioning  systems  because 
the  cost  to  replace  such  a  far-reaching 
capability  is  prohibitive.  Previous 
investments  in  customized  integration 
with  the  system  are  not  easily 
abandoned.  With  today’s  technologies  it 
is  becoming  possible  to  select  COTS 
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systems  based  on  their  modularity  and 
interoperability.  Most  systems  vendors 
are  moving  toward  Web-based  and 
component-based  technologies. 

New  functional  capabilities  -  In  addition 
to  the  fundamental  changes  described 
above,  there  are  a  large  number  of 
specific  applications  that  could  be 
developed  somewhat  independently. 
This  category  is  somewhat  of  a  catchall 
for  those  capabilities. 

These  categories  have  been  described  in 
the  order  of  proposed  prioritization.  The 
rationale  for  this  prioritization  is 
different  from  that  found  in  shipyards 
nowadays.  Today  the  most  typical 
strategy  for  prioritization  is  to  go  after 
the  low-hanging  fruit  first.  There  may  be 
some  justification  for  this  in  an 
individual  company  -  to  get  the  quickest 
return  on  the  smallest  investment  and 
lowest  risk.  However,  this  approach  does 
not  work  well  for  the  industry  as  a 
whole.  In  the  systems  technology  arena 
many  of  the  potential  benefits  are 
interdependent  -  originating  from  the 
basic  notion  of  improving  efficiency  by 
creating  a  re-usable  model  of  the 
product.  The  completion  of  the 
shipbuilding  product  model  is  the  first 
priority.  It  is  a  pervasive  undertaking.  It 
entails  a  number  of  parallel  activities  - 
including  influencing  the  major  systems 
vendors  (CAD,  CAM,  PDM,  ERP,  etc). 
It  entails  coordination  across  domains  - 
CAD  systems  must  capture  the 
necessary  information  to  support 
manufacturing  requirements;  CAM 
systems  must  capture  the  necessary 
information  to  support  accuracy  control 
requirements.  Even  in  advance  of  this 
stage  the  shipbuilding  industry  as  a 
whole  needs  to  agree  upon  those 
information  requirements.  This  activity 


is  complicated  by  issues  of  competition 
and  by  the  sheer  magnitude  of  such  a 
collaboration.  The  work  has  already 
begun  in  the  STEP  arena  but  it  must  be 
significantly  expanded  as  described  in 
the  items  listed  below. 

The  second  priority  is  the  adoption  of 
modular  and  interoperable  systems.  This 
set  of  tasks  is  particularly  hard  to  sell 
because  the  benefits  are  perceived  by 
some  as  intangible.  The  shipbuilder,  who 
easily  recognizes  the  benefits  of  using 
standard  parts  to  build  a  ship,  does  not 
always  recognize  the  advantage  of  using 
standard  software  or  data  components. 
However,  the  benefits  from  this 
approach  are  almost  as  far-reaching  as 
the  benefits  attributable  to  a  complete 
product  model.  Most  of  the  essential 
functions  required  for  ship  design  and 
construction  are  supported  by  available 
systems.  What  is  missing  is  the  ability  to 
continuously  improve  these  systems.  For 
this  to  happen  the  systems  themselves 
need  to  be  modular  (small  enough  to  be 
replaced  without  prohibitive  cost  and 
available  from  more  than  one  vendor) 
and  interoperable  (able  to  share  inputs 
and  outputs  with  the  other  shipbuilding 
systems).  These  activities  can  be  seen  as 
the  final  step  in  the  re-use  of  the  product 
model.  Once  a  complete  product  model 
has  been  constructed,  it  still  remains  to 
share  its  benefits  with  other  users. 

The  final  priority  items  are  those  that 
represent  independently  developable 
functions.  It  should  be  straightforward  to 
obtain  these  capabilities;  however,  their 
benefits  are  circumscribed  and  do  not 
extend  beyond  the  process  at  hand. 

The  following  is  the  prioritized  roadmap. 
Each  line  item  corresponds  to  an 
opportunity  that  is  described  in  one  of 
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the  sections  above.  The  section  is  in 
parentheses. 

PRIORITIZED  ROADMAP 

Deployment  of  a  complete  product 
modeling  capability: 

(CAD)  CAD/PDM  system 
enhancements  (e.g.  instance 
management) 

(CAD)  Feature-based  design 
(Product  model)  Digital  product 
specification 

(LOFT)  Feature-based  design  product 
models 

(ROBOTICS)  Integration  with  the 
design  process 

(ASBUILT)  Matching  inspection 
features  with  design  features 
(ASBUILT)  Improved  means  for 
processing  critical  dimensions 
(ERP)  As-built  and  as-maintained 
product  models 

Adoption  of  modular,  in  teroperable 
systems 

(CAD)  CAD/PDM  data  sharing 
(LOFT)  Improved  interface  to  accuracy 
control  systems 

(LOFT)  Move  away  from  obsolete  data 
formats 

(LOFT)  Better  support  for  inter¬ 
company  data  sharing 
(LOFT)  Improved  interoperability  with 
ERP  data 

(LOFT)  Decoupling  CAD  and  CAM 
data 

(NEST)  Improved  integration  with  ERP 
data 

(NEST)  Part  identifiers  for  accuracy 
control 

(PIPE)  Standard  CAD/CAM  exchange 
format 

(SHEET)  Standard  CAD/CAM 
exchange  format 


(ROBOTICS)  Improved  software  tools 
(ROBOTICS)  Interoperability  and 
standard  data  formats 
(ASBUILT)  Standards  for  the 
interoperability  of  as-built  data 
(ERP)  Modular  ERP  capabilities 
(ERP)  Interoperability  of  ERP  and  life- 
cycle  support  systems 
(VIZ)  Data  management  and  integration 
with  design  PDM 
(VIZ)  Integration  with  MRP  and 
construction  data 

(PM&S)  Standard  for  process  data 
definition 

(PM&S)  Process  knowledge  and 
management 

New  functional  capabilities 

(LOFT)  Product  data  management  for 
CAM  (lofting)  data 
(LOFT)  Automation  of  lofting  process 
(PIPE)  CAD/CAM  rules  checking 
(PIPE)  Automated  planning 
(PIPE)  PDM  capabilities  for 
configuration  management 
(PIPE)  Interference  checking 
(ROBOTICS)  Changes  in  construction 
planning  and  scheduling 
(ROBOTICS)  Cutting  and  material 
preparation 

(ROBOTICS)  Reuse  of  skill  and 
knowledge  resources 
(ROBOTICS)  Specialized  techniques  for 
thick  sections 

(ASBUILT)  Product  data  management 
for  as-built  data 

(ASBUILT)  Specialized  inspection  tools 
(ASBUILT)  Feature  recognition  from 
point  clouds 

(ASBUILT)  Visualization  tools 
(ASBUILT)  Build  to  fit/reverse 
engineering 

(PM&S)/(Lean)  Ease  of  use  -  Process 
Mapping 

(RP)  Dynamic  interference  checking 
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(VIZ)  Visualization  on  the  shop  floor 
(VIZ)  Distributed  desktop  visualization 

Recommendations 

Based  on  this  report,  further  research 
should  be  planned  in  the  areas  of 
opportunities  outlined  in  the  above 
roadmap.  The  major  stakeholders 
should  be  involved  with  reviewing  the 
areas  of  opportunity  and  translating  them 
into  an  action  plan.  This  action  plan 
could  be  similar  to  the  Strategic 
Investment  Plan  (SIP)  published  by 
NSRP.  This  new  strategic  plan  could 
then  be  used  to  help  direct  future 
research  announcements  and  project 
selections. 
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